Question

We have a table with a key field, and another table which contains the current value of that key sequence, ie, to insert a new record you need to:

UPDATE seq SET key = key + 1
SELECT key FROM seq
INSERT INTO table (id...) VALUES (@key...)

Today I have been investigating collisions, and have found that without using transactions the above code run in parallel induces collisions, however, swapping the UPDATE and SELECT lines does not induce collisions, ie:

SELECT key + 1 FROM seq
UPDATE seq SET key = key + 1
INSERT INTO table (id...) VALUES (@key...)

Can anyone explain why? (I am not interested in better ways to do this, I am going to use transactions, and I cannot change the database design, I am just interested in why we observed what we did.)

I am running the two lines of SQL as a single string using C#’s SqlConnection, SqlCommand and SqlDataAdapter.

Answer 1

First off, your queries do not entirely make sense. Here’s what I presume you are actually doing:

UPDATE seq SET key = key + 1
SELECT @key = key FROM seq
INSERT INTO table (id...) VALUES (@key...)

and

SELECT @key = key + 1 FROM seq
UPDATE seq SET key = @key
INSERT INTO table (id...) VALUES (@key...)

You’re experiencing concurrency issues tied to the Transaction Isolation Level.

Transaction Isolation Levels represent a compromise between the need for concurrency (i.e. performance) and the need for data quality (i.e. accuracy).

By default, SQL uses a Read Committed isolation level, which means you can’t get “dirty” reads (reads of data that has been modified by another transaction that but not yet committed to the table). It does not, however, mean that you are immune from other types of concurrency issues.

In your case, the issue you are having is called a non-repeatable read.

In your first example, the first line is reading the key value, then updating it. (In order for the UPDATE to set the column to key+1 it must first read the value of key). Then the second line’s SELECT is reading the key value again. In a Read Committed or Read Uncommitted isolation level, it is possible that another transaction meanwhile completes an update to the key field, meaning that line 2 will read it as key+2 instead of the expected key+1.

Now, with your second example, once the key value has been read and modified and placed in the @key variable, it is not being read again. This prevents the non-repeatable read issue, but you’re still not totally immune from concurrency problems. What can happen in this scenario is a lost update, in which two or more transactions end up trying to update key to the same value, and subsequently inserting duplicate keys to the table.

To be absolutely certain of having no concurrency problems with this structure as designed, you will need to use locking hints to ensure that all reads and updates to key are serializable (i.e. not concurrent). This will have horrendous performance, but “WITH UPDLOCK,HOLDLOCK” will get you there.

Your best solution, if you cannot change the database design, is to find someone who can. As Brian Hoover indicated, an auto-incrementing IDENTITY column is the way to do this with superb performance. The way you’re doing it now reduces SQL’s V-8 engine to one that is only allowed to fire on one cylinder.