Object doesn't create seperate instances for each session

[Markus Prediger]

Hi NG,

I have an asp.net project that uses an vb6 com object for some
database-manipulation (I cannot rewrite it in .net, sorry, its not my
decision).

I want it to be instanciated seperately for each session, so that three
users can connect to three different databases. But I get crazy because:

-With interop all users share one instance - pure chaos (the instance is
guilty for the whole app grrrrrmmmmml...)
-integrated it in global.asax and using the static objects collection forces
me to change the whole code to get access and I have to be sure to write
correct code from my mind because there is no code completion...

Is there a way to have the object in my project with interop and having it
for each session seperatly and not about the whole application?


thx,
best regards,

Markus Prediger

 

[Bruce Barker]

your analysis is incorrect, interop does not force single instance (only
shared or static variables cause this effect)

vb6 com objects are apartment model com objects, and not supported by
default with asp.net (which is designed for free threaded objects). an
apartment model objects must be called from the same thread that created
them, vb6 com objects store state info in thread local storage, so this rule
is very important with them.

you can use the aspcompat flag (required to call vb6 com objects), which
forces a calls to an sta object to use a thread from the STA pool. if you
stick an sta object in session (with aspcompat on), then that thread is
bound to the session. the same thread will be used to service request using
that session. thus all calls to the session object use the same thread. if
you create multiple instances of an sta object and store in different
sessions, each instance will have a dedicated thread.

the best performance would be to create and destroy your vb6 com object on
each page. then you only lose thread agility, as request threads come from
the STA pool.

to recap, set aspcompat on every page that references your vb6 component. do
not store the object in a shared variable, or a module level variable

note: sta com objects are not supported by webservices, you need to write
your own sta threading handlers for this.

-- bruce (sqlwork.com)

 

[Markus Prediger]

Hi Bruce,

very thank you for your Help!!!

you are completely right, I yesterday recognized that the only way to use it
with seperate instances is to declare it in the frontend of global.asax
(<object id=...) and to use it with
Session.StaticObjects("com-instance").method. Then it works perfect, but
with absolutly no help (code completion etc.) from the IDE. The
aspcompat-attribute I've already inserted a long time ago, hoping it would
work so... ;-( . I'm a little bit sad that M$ did not integrate this more
developer-frienly...
Ok everybody says to rewrite everything in .net, but we both do not have
time and money to rewrite this component AND put it into the other 12 or 15
vb6-applications for client pcs that use it. Maybe in 5 or 10 years we will
have it, but not at the moment.

To your idea: "the best performance would be to create and destroy your vb6
com object on each page." I also tried but the object is for the whole
database connection to mssql server and to have it opened and closed for
each request wouldn't be very performant.

But I have another question, because I have another object that I really
instanciate for one request (in one *.aspx.vb file) and then kill again (it
is included with interop). If two users do the same page request, will they
also have the same instances? With your description, it would be so. So for
having clean code, I have to instance it, put it into the session
(session.add) and use this instance (again no code completion any more). How
will I kill this instance in the end??

mfg and thx again,

Markus Prediger


your analysis is incorrect, interop does not force single instance (only
shared or static variables cause this effect)

vb6 com objects are apartment model com objects, and not supported by
default with asp.net (which is designed for free threaded objects). an
apartment model objects must be called from the same thread that created
them, vb6 com objects store state info in thread local storage, so this rule
is very important with them.

you can use the aspcompat flag (required to call vb6 com objects), which
forces a calls to an sta object to use a thread from the STA pool. if you
stick an sta object in session (with aspcompat on), then that thread is
bound to the session. the same thread will be used to service request using
that session. thus all calls to the session object use the same thread. if
you create multiple instances of an sta object and store in different
sessions, each instance will have a dedicated thread.

the best performance would be to create and destroy your vb6 com object on
each page. then you only lose thread agility, as request threads come from
the STA pool.

to recap, set aspcompat on every page that references your vb6 component. do
not store the object in a shared variable, or a module level variable

note: sta com objects are not supported by webservices, you need to write
your own sta threading handlers for this.

-- bruce (sqlwork.com)