object persistence

So, I'm using a 3rd party com object via interop (already I can hear screams
of anguish). This object was originally written to be used as the backend
for multiple screens of a VB application. Now in this situation the object
remains in memory the whole time, so persistence of data between screens is
not a problem, but on the web I'm assuming (from previous experience) that
we'll need to use Load and Commit methods on this object - where the object
persists its own data to whatever datastore it utilises between requests (as
long as I call these methods, of course).

Ok. With me so far? :)

It has been suggested to me that rather than use these methods (which
apparently haven't been implemented) I should store the object in the
Session. This sounds horrendous, particularly because the object isn't
serializable but also because it's quite a large object.

It's also been suggested that I add a module which stores and persists the
object, but afaict all this does is create ONE instance of the class and
then all sessions would use that. Which is a bit pointless really.

I'm thinking that I have ample reason for them to get working and implement
those Load/Commit methods, but might there be other relatively simple ways
to persist the object on a per session basis that I just haven't thought of?

--
jo inferisIf this is a VB6 COM component - you won't want the object anywhere
near the Session collection, or operating as a singleton in a module.

http://support.microsoft.com/kb/817005
(Although this hotfix fixes a severe performance issue - aspcompat
mode is still a performance issue in and of itself).

Does the object itself have to persist the data? Could you ask the
object to, say, give you back an XML representation of the data so you
could do anything with it?

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Thu, 17 Feb 2005 16:15:49 -0000, "Jo Inferis"
<jo@.inferis.NOSPAM.gotadsl.co.uk> wrote:

>So, I'm using a 3rd party com object via interop (already I can hear screams
>of anguish). This object was originally written to be used as the backend
>for multiple screens of a VB application. Now in this situation the object
>remains in memory the whole time, so persistence of data between screens is
>not a problem, but on the web I'm assuming (from previous experience) that
>we'll need to use Load and Commit methods on this object - where the object
>persists its own data to whatever datastore it utilises between requests (as
>long as I call these methods, of course).
>Ok. With me so far? :)
>It has been suggested to me that rather than use these methods (which
>apparently haven't been implemented) I should store the object in the
>Session. This sounds horrendous, particularly because the object isn't
>serializable but also because it's quite a large object.
>It's also been suggested that I add a module which stores and persists the
>object, but afaict all this does is create ONE instance of the class and
>then all sessions would use that. Which is a bit pointless really.
>I'm thinking that I have ample reason for them to get working and implement
>those Load/Commit methods, but might there be other relatively simple ways
>to persist the object on a per session basis that I just haven't thought of?
Scott Allen wrote:
> If this is a VB6 COM component -
It is...

> you won't want the object anywhere
> near the Session collection, or operating as a singleton in a module.
> http://support.microsoft.com/kb/817005
Gah. I hadn't really considered this kind of thing. Just thinking about
threads in general tends to give me a headache.

Thanks for the heads up though.

...actually (he says after some brief reading up) - is this relevant for
..NET 1.1? (the hotfix above relates to 1.0) I've never actually bothered
with the ASPCompat attribute and the pages run fine, where the documentation
about this says that it must be set to true otherwise the runtime will
generate an error...

> Does the object itself have to persist the data?
> Could you ask the
> object to, say, give you back an XML representation of the data so you
> could do anything with it?

Sadly, no. I'd then have to write my own routines for saving the data and
loading it back into the object on each request anyway.

The only tantalising option then is the existence of the Load/Commit
methods. I'm hoping I can get them implemented so all I have to store is a
Session ID.

--
jo inferis
On Fri, 18 Feb 2005 11:17:50 -0000, "Jo Inferis"
<jo@.inferis.NOSPAM.gotadsl.co.uk> wrote:

>...actually (he says after some brief reading up) - is this relevant for
>.NET 1.1? (the hotfix above relates to 1.0) I've never actually bothered
>with the ASPCompat attribute and the pages run fine, where the documentation
>about this says that it must be set to true otherwise the runtime will
>generate an error...

I don't think there will be an error - but it is an additional
performance hit as the request has to switch threads when it calls
into the component. I'm not saying the software won't work - but you
might want to do some stress testing to make sure it can keep up with
your user demand.

--
Scott
http://www.OdeToCode.com/blogs/scott/