title: Shared lock in READ_COMMITTED_SNAPSHOT and SNAPSHOT isolation
body: <p>I've read on Microsoft's site 
  <a href="http://msdn.microsoft.com/en-us/library/ms173763.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/ms173763.aspx</a></p>
  
  <p>that Sql Server doesn't request locks when reading data, except when a database is being recovered.</p>
  
  <p>Does it mean that Sql Server using  READ_COMMITTED_SNAPSHOT/SNAPSHOT ISOLATION doesn't use shared locks at all?
  How is that possible?</p>
  
  <p>For example, if there are 2 transactions.
  First transaction T1 wants to update some row.
  Second transaction T2 starts reading same row (this transaction is copying him to some output buffer, response buffer or whatever it's called in Sql Server).
  At the same time transaction T1 starts updating that row (it created versioned row first).</p>
  
  <p>Isn't there a possibility that transaction T2 will read uncommited data?
  Remember, transaction T2 started copying that row before T1 made update, so there is no exclusive lock on that row.</p>
  
  <p>Is this situation even possible and how can this be avoided without setting shared lock on that row during copying of it's data?</p>