>Hi Rick,
>
>Thanks for your input. Reloading the object and reestablishing the state definitely appears to be the way to go. I've read where it's recommended to limit (or eliminate entirely) use of session variables. Do you agree?

It's not really the amount of session variables but the amount of data that is stored. You can have one object that's huge (like a DataSet) and that will be more intensive than 20 separate vars. The overhead is in hte serialization and the other issue is size.

+++ Rick ---



>
>Dan
>
>>Dan,
>>
>>Generally its a really bad idea to store COM objects into Session (or worse Applicatin objects), because these objects need to be marshalled back to the original thread they were created on (at least VFP/VB COM objects that is). This means at best a lot of overhead for getting these objects back, and at worst deadlock situations if threads are busy and used by two objects at the same time.
>>
>>This sort of thing usually works fine in low load scenarios, but as soon as you load the server this causes problems and can cause as you've found out inconsistent lock up scnearios.
>>
>>The whole COM mechanism for dealing with persistedf objects beyond a single hit is very unstable in IIS in my experience. You are likely much better off reloading the object and restablishing state which is probably a better design anyway for a Web application to avoid resource usage overload for these objects cached in a Session object.
>>
>>
>>+++ Rick ---
>>