views:

27

answers:

1

I'm currently working on solving a bug with a site I've been working on for some time now. The issue I'm having is my session objects are being overwritten occasionally when users call the site at the same time.

My current session mode is In-Proc and after reading another thread regarding a similar issue I believe my problem may be related.

The site uses Sql Reporting Services to generate some legal documents by querying a database and using XML from two different web services. In the session I store a custom object that contains members holding the data to generate the document in SRSS.

The issue I'm having happens when I open two instances of the site at the same time. The Session IDs are different, but when I begin generating the forms the two objects tromp all over each others data somehow. I'm still not quite sure how it's happening.

My thoughts thus far have been to attempt to store some of the more sensitive members of the class in the session explicitly to see if that would help correct some of the corruption, or to move over to another form of session management. I have access to a SQL server so I could use the SQL session storage mode.

Anyone have any recommendations/ideas?

A: 

My guess would be that the custom object that you're storing in session may:

  1. have some static variables.
  2. reference another object that has static variables.
  3. also be stored in the Application or Cache dictionary or in a static variable somewhere.
  4. reference an object that is also stored in the Application or Cache dictionary or in a static variable somewhere.

I would suggest analyzing the object graph of the object that you're storing in session to see if there are any parts of it that are accessible from multiple threads based on criteria 1, 2, and 4 above.

If everything looks fine with the object graph, then I'd probably start looking at how that object is populated, looking for any cases of 3 or 4.

Dr. Wily's Apprentice
Thanks for the help with that one. I noticed in the code when I was stepping through that the web service handler class was returning old XML regardless of the user. Turns out the person that wrote the class was using static strings that were being sent to the WebService and the strings were storing the old data between site calls.
Philter