Comments on: The Potential Dangers of the Read Committed Snapshot Isolation Level http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/ Musings about SQL, databases, and my world in general... Tue, 20 Dec 2011 15:37:13 +1000 http://wordpress.org/?v=2.8.6 hourly 1 By: Umasankar http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/comment-page-1/#comment-28500 Umasankar Wed, 24 Aug 2011 10:34:11 +0000 http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/#comment-28500 Good example to demonstrate the negetive effect of Read commmited snapshot. subsequent Comment that suggested to place Updlock,rowlock is also good way around.Thank you. Good example to demonstrate the negetive effect of Read commmited snapshot. subsequent Comment that suggested to place Updlock,rowlock is also good way around.Thank you.

]]> By: Adam http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/comment-page-1/#comment-25988 Adam Wed, 25 May 2011 00:43:57 +0000 http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/#comment-25988 This post is very interesting and quite intriging, but I got truly lost. How a good quality code performing the above shoold look like? How to do excactly what the code is doing in snapshot isolation and without it? This post is very interesting and quite intriging, but I got truly lost.

How a good quality code performing the above shoold look like?

How to do excactly what the code is doing in snapshot isolation and without it?

]]> By: Chef Zoff http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/comment-page-1/#comment-18390 Chef Zoff Tue, 09 Mar 2010 16:20:17 +0000 http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/#comment-18390 I must say that the example is not the best, but also I have to recognize that it is a true real life example of how bad people write queries. Obviously that we can write better, more consistent and efficient code ways, but the ugly true is that you will find always code like the example, how many developers knows the SQL hints? I think that the example provides maybe one of the most common and lame scenario that we can fine. I must say that the example is not the best, but also I have to recognize that it is a true real life example of how bad people write queries. Obviously that we can write better, more consistent and efficient code ways, but the ugly true is that you will find always code like the example, how many developers knows the SQL hints? I think that the example provides maybe one of the most common and lame scenario that we can fine.

]]> By: Lions and Tigers and Deadlocks OMY! - rosslotharius.com http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/comment-page-1/#comment-18381 Lions and Tigers and Deadlocks OMY! - rosslotharius.com Mon, 08 Mar 2010 16:30:08 +0000 http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/#comment-18381 [...] There are known concerns with Read Committed Snapshot that mainly exist in older applications that were developed without this isolation level in mind.  For a more detailed description, I recommend checking out this blog post here.  [...] [...] There are known concerns with Read Committed Snapshot that mainly exist in older applications that were developed without this isolation level in mind.  For a more detailed description, I recommend checking out this blog post here.  [...]

]]> By: Jim http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/comment-page-1/#comment-13924 Jim Fri, 28 Aug 2009 01:01:01 +0000 http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/#comment-13924 I agree with all comments so far. I'm definitely not making excuses for this code - it's terrible, but under a pessimistic concurrency model it works "well enough". And if it works "well enough", then there's a possibility that someone working for your application vendor has written code like this without a thought as to concurrency models. In my horrible code sample, this "well enough" has gone from "good enough to work, but still a small chance of problems" to "guaranteed to break much more often" due to the longer available window the row is committed under RCS. The point of the post comes down to this: if you're reading data from a table, and something happens to be modifying the data, and the original developer expects the code to wait until the lock occurs, then you'll be in trouble if you turn on READ COMMITTED SNAPSHOT to try to reduce blocking. The idea of the post originally came from a forum post where a guy performed an BEGIN TRAN...UPDATE and didn't commit or rollback, and wanted to know if there was a way to not block other users (well, apart from committing). noeldr, regarding your point #1, the SUM() was from an evolution of the code and can be removed. It took me a while to write code this bad! :) I agree with all comments so far.

I’m definitely not making excuses for this code – it’s terrible, but under a pessimistic concurrency model it works “well enough”. And if it works “well enough”, then there’s a possibility that someone working for your application vendor has written code like this without a thought as to concurrency models. In my horrible code sample, this “well enough” has gone from “good enough to work, but still a small chance of problems” to “guaranteed to break much more often” due to the longer available window the row is committed under RCS.

The point of the post comes down to this: if you’re reading data from a table, and something happens to be modifying the data, and the original developer expects the code to wait until the lock occurs, then you’ll be in trouble if you turn on READ COMMITTED SNAPSHOT to try to reduce blocking.

The idea of the post originally came from a forum post where a guy performed an BEGIN TRAN…UPDATE and didn’t commit or rollback, and wanted to know if there was a way to not block other users (well, apart from committing).

noeldr, regarding your point #1, the SUM() was from an evolution of the code and can be removed. It took me a while to write code this bad! :)

]]> By: Niels Berglund http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/comment-page-1/#comment-13923 Niels Berglund Thu, 27 Aug 2009 23:49:28 +0000 http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/#comment-13923 I must agree with AK here; the way your code is written you are vulnerable in either case. The only reason you are not seeing as frequent in your READ COMMITTED scenario is due to where you have the waitfor delay statement. Move the waitfor delay, up to after you are selecting the quantity - and you will see the same behavior with "normal" RC. If this is a scenario you are concerned about, then you should use an update locking hint in your select (but you know that already :) ). Niels I must agree with AK here; the way your code is written you are vulnerable in either case. The only reason you are not seeing as frequent in your READ COMMITTED scenario is due to where you have the waitfor delay statement. Move the waitfor delay, up to after you are selecting the quantity – and you will see the same behavior with “normal” RC.

If this is a scenario you are concerned about, then you should use an update locking hint in your select (but you know that already :) ).

Niels

]]> By: SqlServerKudos http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/comment-page-1/#comment-13920 SqlServerKudos Thu, 27 Aug 2009 22:19:29 +0000 http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/#comment-13920 <strong>The Potential Dangers of the Read Committed Snapshot Isolation Level...</strong> Kudos for a great Sql Server article - Trackback from SqlServerKudos... The Potential Dangers of the Read Committed Snapshot Isolation Level…

Kudos for a great Sql Server article – Trackback from SqlServerKudos…

]]> By: noeldr http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/comment-page-1/#comment-13911 noeldr Thu, 27 Aug 2009 17:17:31 +0000 http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/#comment-13911 This could not have been a worse sample to blame it to the isolation level. There are many things wrong with your code. 1. LocationId + ItemID was defined as the PK of the table so there can only be ONE Qty for the pair, then why SUM() ? 2. You are suposed to use (QUERY HINT) locks if you are running this in separated statements even with read commited isolation. A simple with (UPDLOCK,ROWLOCK) will suffice on the select query to make the code work under any isolation level. 3. IF you turn the Update as an update + Read operation it will go all smoothly into a single statement which will maintain all ACID properties and no hint is needed at all. This could not have been a worse sample to blame it to the isolation level.
There are many things wrong with your code.
1. LocationId + ItemID was defined as the PK of the table so there can only be ONE Qty for the pair, then why SUM() ?
2. You are suposed to use (QUERY HINT) locks if you are running this in separated statements even with read commited isolation. A simple with (UPDLOCK,ROWLOCK) will suffice on the select query to make the code work under any isolation level.
3. IF you turn the Update as an update + Read operation it will go all smoothly into a single statement which will maintain all ACID properties and no hint is needed at all.

]]> By: Jim http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/comment-page-1/#comment-13901 Jim Thu, 27 Aug 2009 00:41:42 +0000 http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/#comment-13901 Hi AK, Thanks for your comment! In the example, READ COMMITTED (RC) is safer than READ COMMITTED SNAPSHOT (RCS) as the RC UPDATE will lock the row, and the second session will be blocked until the update has finished. Whereas with RCS, they both read the same data without locks, and as the transaction takes a number of seconds to process, there's a higher chance that the two will be in conflict. RC is vulnerable as well, but the chance of it occurring is a lot smaller, as the window is only between the time the of the the SELECT Qty and the UPDATE Qty. Whereas RCS allows the problem to creep in any time during the 10 second transaction. As I said, it wasn't perfect code - but it's code of a quality that I have seen before. The problem isn't so much the code, as the effect of changing the entire database's READ COMMITTED behavior from a pessimistic concurrency model to an optimistic concurrency model. It can change the entire behavior of the application. Hi AK,

Thanks for your comment!

In the example, READ COMMITTED (RC) is safer than READ COMMITTED SNAPSHOT (RCS) as the RC UPDATE will lock the row, and the second session will be blocked until the update has finished. Whereas with RCS, they both read the same data without locks, and as the transaction takes a number of seconds to process, there’s a higher chance that the two will be in conflict.

RC is vulnerable as well, but the chance of it occurring is a lot smaller, as the window is only between the time the of the the SELECT Qty and the UPDATE Qty. Whereas RCS allows the problem to creep in any time during the 10 second transaction.

As I said, it wasn’t perfect code – but it’s code of a quality that I have seen before. The problem isn’t so much the code, as the effect of changing the entire database’s READ COMMITTED behavior from a pessimistic concurrency model to an optimistic concurrency model. It can change the entire behavior of the application.

]]> By: AK http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/comment-page-1/#comment-13897 AK Wed, 26 Aug 2009 22:05:40 +0000 http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/#comment-13897 I cannot agree with your conclusion. SNAPSHOT will give you a correct point in time picture. READ COMMITTED is just as vulnerable to the problem you are demonstrating as READ COMMITTED SNAPSHOT is. Examples: http://www.simple-talk.com/sql/t-sql-programming/the-case-of-the-skewed-totals/ http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/04/10/selects-under-read-committed-and-repeatable-read-may-return-incorrect-results.aspx I cannot agree with your conclusion. SNAPSHOT will give you a correct point in time picture. READ COMMITTED is just as vulnerable to the problem you are demonstrating as READ COMMITTED SNAPSHOT is.

Examples:

http://www.simple-talk.com/sql/t-sql-programming/the-case-of-the-skewed-totals/

http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/04/10/selects-under-read-committed-and-repeatable-read-may-return-incorrect-results.aspx

]]>