Session corrupt using aspnet_state service

Question

We have for some time now been experiencing problems with data being saved in our SQL database.

Sometimes records are saved with data that does not match the rest of the row, making it seem like at some point, data is being 'swapped' for something else, perhaps, another user's data, before being passed to the database.

We do use TransactionScopes throughout with Isolation Level of ReadCommitted which makes me think the data integrity issue lies within the application rather than at the Database level.

We do use the session extensively and we are starting to think that the times of the corrupt data are similar to the times we deploy updates to the system during the day.

We do use the aspnet_state service to persist the session over application restarts.

Our users rely on terminal sessions therefore multiple users all log into the same server and launch the system via a browser.

We have in the past noticed users logging in with the same domain credentials but we are now relatively confident that users now log in with unique accounts.

99.9% of the data is correct but we have been struggling to understand what could be causing this intermittent data integrity issue.

We are now limiting our deploys to outside working hours on pain of death, but this is not always possible.

Can anyone shed light on why/how this might be happening?

EDIT: We have now isolated this to the DAL layer, see SQL query returns incorrect value in multi user environment

Answer 1

I have recently been fighting this!, and had similar problem to yours around 95% of the data written back was correct. I looked at various reasons why, the main culprit was some users on the network had downloaded Chrome and opening the record within Chrome, breaking our session id's as Chrome ignores sessions.

The other cause had been either the users was not closing the browser or not logging off the application allowing either the same user or completely different user to pick and use the session id.

After introducing a browser check and then reject Chrome, educating the users to make sure they log off, doing any updates to outside busy periods the problem was just about gone.

I forgot to mention, also on your IIS its best to turn off caching in the Output Caching, for the user and kernal set to prevent caching.