vb dll instancing in Session variables

[KyleC]

Disclaimer: I'm fully aware that the following is not the proper way to
do things, and that one should never, ever create objects in Session
scope, but it's all I've got to work with until the next version of the
application is released. That aside...

I'm in charge of a web application that creates a Apartment-threaded VB
dll and places it in a Session variable for each user during
Session_OnStart . The dll controls all database transactions (Access
database) and holds specific user info. The idea is that each user
accessing the web application would get their own instance of the dll
and that there would be no shared data among users logged in.

The application has worked fine for the last 4 years. Recently, the
dll code was changed to include .bas modules (the previous version used
only classes). More recently still, I noticed that information one
user was entering into the application was being saved into another
user's record that the second user was editing. I haven't been able to
reproduce the error, although when the original error occurred there
were around 15 concurrent users online.

Thinking it had something to do with the recent change, the dll was
reworked to get rid of the .bas modules. I still haven't been able
reproduce the error but I'm still leery as to whether the problem was
truly fixed or if the application has been "broken" all along and it
took 15 concurrent users to create the problem.

That's a long way around to my question, which is this: Does the setup
mentioned above actually create a new instance of the dll for each user
and is that instance "safe" from other users? I want to be sure that
each user has access to his own separate instance of the dll and only
that instance.

Thanks,
-KyleC

[Patrice]

IMO this is caused by the module stuff. It doesn't create a "DLL" instance
but a class instance. So if each class instance has its own data, no
problem. If they use a variable level module, they will share the same
value... (as modules are not instanciated).

--

Patrice

"KyleC" <so***********@ charter.net> a écrit dans le message de
news:11******** **************@ g43g2000cwa.goo glegroups.com.. .

Disclaimer: I'm fully aware that the following is not the proper way to
do things, and that one should never, ever create objects in Session
scope, but it's all I've got to work with until the next version of the
application is released. That aside...

I'm in charge of a web application that creates a Apartment-threaded VB
dll and places it in a Session variable for each user during
Session_OnStart . The dll controls all database transactions (Access
database) and holds specific user info. The idea is that each user
accessing the web application would get their own instance of the dll
and that there would be no shared data among users logged in.

The application has worked fine for the last 4 years. Recently, the
dll code was changed to include .bas modules (the previous version used
only classes). More recently still, I noticed that information one
user was entering into the application was being saved into another
user's record that the second user was editing. I haven't been able to
reproduce the error, although when the original error occurred there
were around 15 concurrent users online.

Thinking it had something to do with the recent change, the dll was
reworked to get rid of the .bas modules. I still haven't been able
reproduce the error but I'm still leery as to whether the problem was
truly fixed or if the application has been "broken" all along and it
took 15 concurrent users to create the problem.

That's a long way around to my question, which is this: Does the setup
mentioned above actually create a new instance of the dll for each user
and is that instance "safe" from other users? I want to be sure that
each user has access to his own separate instance of the dll and only
that instance.

Thanks,
-KyleC

[KyleC]

Thanks for the reply. That was what I was hoping to hear.

-Kyle