Problem with public objects being available for other sessions in a multi threaded dll

Hi,

I'm having a problem with public objects being available for other sessions in a multi threaded dll.

To describe the actual problem;

The MT DLL (built using Microsoft Visual FoxPro) is used as a COM+ for a web based application. On occasions it has been noticed that certain public objects created in one users session is accessible from another users session (as it displays info related to user1 session).

If the public object is not released this can be simulated consistently, which I assume is bcos for user2 the object is not created in his session, but rather uses the un-released object from the other users session,

Is there any reason why this occurs?

Is it a problem with how the component has been created? We have tried creating it as a Library Application as well as Server Application but
this does not seem to solve the problem.

Further we have tried the option when building the DLL via VFP Project Manager after changing the Instancing to Single Use in the Servers tab.

This too did not help.

The DLL is a collection of several visual fox pro classes.

Any help on this would be really appreciated.

Thanks
QClient.
LVL 1
ananmananAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

AlexFMCommented:
I don't work with Visual FoxPro but have some experience with COM+. One of COM+ requirements is that all objects must be stateless. Every call to object's method must keep inside it all required information. COM+ manages pool of components and supplies any free component for client call.
When client calls two COM+ component methods, they can be served by different object instances.
In COM+ model, it is impossible to keep persistent information in class members.

Make WEB search fot "COM+ stateless" for more information. You need to redesign your COM+ component according to this requirement. Any persistent information must be kept by client, and not server.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Programming

From novice to tech pro — start learning today.