home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.databases.ms-sqlserver      Notorious Rube Goldberg contraption      19,505 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 18,346 of 19,505   
   Erland Sommarskog to b.f.lundin@gmail.com   
   Re: isolation level snapshot, how does i   
   05 Jun 11 14:35:58   
   
   22c70484   
   From: esquel@sommarskog.se   
      
   björn lundin (b.f.lundin@gmail.com) writes:   
   > Well yes. But I put the code there to illustrate some requirements   
   > that I have   
   > * MARS, or multiple active record sets. It is used a lot.   
      
   Ugh! I can't say that MARS is anything I recommend. When used correctly, it   
   is not likely to be harmful, but it can lure you do things you should not   
   do.   
      
   > * The statements are prepared, and late on bound.   
      
   Still a stored procedure that performs all the business logic will   
   more efficient that sending data forth and back between server and client.   
      
   > But in reality, there were 3 more steps   
   >   
   > -1, Process A sets isolation level to snapshot   
   > 0 , Process A starts new transaction by setting autocommit to off   
   > 5.5 process A commits (sqlEndTran(commit))   
      
   So it's not process B that has an uncommitted transaction as I assumed,   
   but process A. The effect is the same.   
      
   > However, it all worked in READ_COMMITTED mode, which implies on of two   
   > things   
   > * Process B got a dirty read   
   > * The Snapshot handling is so much slower that Process B was too quick   
   > reading,   
   >   so Process A had not yet done its final commit. And when not using   
   > snapshot,   
   >   process A send the IPC, and committed, BEFORE Process A got to   
   > read.   
   >   
   > I prefer to believe its the second option, but will keep my eyes on it   
   > until I know for sure.   
      
   Not really. But without snapshot, B was blocked until A had performed its   
   final commit, whereas with snapshot B just reads the old data. No scheme is   
   perfect, and with snapshot - either true snapshot isolation or   
   read_commited_snapshot - the risk is that you read stale data.   
      
   If you have situtaions where a process may be signaled about new data that   
   has not yet been committed, that process cannot use snapshot isolation to   
   read the data. This is the one situation where enabling RCSI can wreak   
   havoc on an application. You can use the hint (READCOMMITTEDLOCK) to   
   prevent this from happening.   
   --   
   Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se   
      
   Links for SQL Server Books Online:   
   SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx   
   SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca