Sessione corrotta utilizzando il servizio aspnet_state

Question

Da qualche tempo stiamo riscontrando problemi con i dati salvati nel nostro database SQL.

A volte i record vengono salvati con dati che non corrispondono al resto della riga, facendo sembrare che ad un certo punto i dati vengano "scambiati" per qualcos'altro, forse, i dati di un altro utente, prima di essere passati al database .

Facciamo uso TransactionScopes in tutto con livello di isolamento di READCOMMITTED che mi fa pensare il problema dell'integrità dei dati si trova all'interno della applicazione, piuttosto che a livello di database.

Usiamo la sessione in modo esteso e stiamo iniziando a pensare che i tempi dei dati corrotti siano simili alle volte in cui distribuiamo gli aggiornamenti al sistema durante il giorno.

Utilizziamo il servizio aspnet_state per mantenere la sessione dopo il riavvio dell'applicazione.

I nostri utenti si affidano alle sessioni del terminale, pertanto più utenti accedono tutti allo stesso server e lanciano il sistema tramite un browser.

Abbiamo notato in passato che gli utenti effettuavano l'accesso con le stesse credenziali di dominio, ma ora siamo relativamente sicuri che gli utenti effettuino l'accesso con account univoci.

Il 99,9% dei dati è corretto, ma abbiamo faticato a capire che cosa potrebbe causare questo problema intermittente di integrità dei dati.

Ora stiamo limitando i nostri spiegamenti al di fuori dell'orario di lavoro, pena la morte, ma questo non è sempre possibile.

Qualcuno può far luce sul perché/come questo potrebbe accadere?

EDIT: ora abbiamo isolato questo allo strato DAL, vedere SQL query returns incorrect value in multi user environment

Answer 1

recente ho combattuto questa !, e aveva problemi simili ai tuoi circa il 95% dei dati scritti sul retro era corretta. Ho esaminato vari motivi per cui il colpevole principale era che alcuni utenti della rete avevano scaricato Chrome e aperto il record in Chrome, interrompendo i nostri ID di sessione mentre Chrome ignorava le sessioni.

L'altra causa era stata che gli utenti non chiudevano il browser o non disconnettevano l'applicazione consentendo allo stesso utente o all'utente completamente diverso di scegliere e utilizzare l'id di sessione.

Dopo aver introdotto un controllo del browser e quindi rifiutato Chrome, istruendo gli utenti per assicurarsi che si disconnettano, facendo gli aggiornamenti al di fuori dei periodi di occupato il problema era quasi finito.

Ho dimenticato di menzionare, anche su IIS, il modo migliore per disattivare la memorizzazione nella cache nella cache di output, per l'utente e il kernal impostato per impedire la memorizzazione nella cache.