Multi-version concurrency / wrong exception is thrown.

[GoogleCodeExporter]

"Concurrent update in table T1: another transaction has updated or deleted 
the same row" right after Update statement

Details (*testSuperConcurrent*):

Two threads with different connections (autocommit disabled) start to 
simultaneously update the same row in single table thousand times with *no 
commit*. In theroy, concurrent updates from the second thread should be 
*blocked* unitl first transaction commits.
Actually, with MVCC such updates are permitted. 

We think that error CONCURRENT_UPDATE_1 (90131) is a design mistake and 
should be replaced with session blocking.

In 114 it was possible only in semi-ansynchroneous way: two threads might 
interfere but only while executeUpdate() is not called in the same time by 
two threads. In 117 even this was broken.

Please check the *unit test*.
With h2.114 only testSuperConcurrent() were failing.
With h2.117, testConcurrentEntityUpdate *start to fail in 117* with the 
same error.

Original issue reported on code.google.com by a.kosenkov on 12 Aug 2009 at 2:58

[GoogleCodeExporter]

I am seeing the same behaviour here.  

As I started using H2 with 116 and have now switched to 117, I can't tell 
whether
this is a regression.

Original comment by mb555...@gmail.com on 14 Aug 2009 at 7:39

[GoogleCodeExporter]

Hi,

Probably the exception message is wrong, it should be a 'lock timeout'. 
Actually, the
database re-tries to update the row, but eventually this times out, and throws 
this
exception. The default lock timeout is 1 second. See also
http://www.h2database.com/html/grammar.html#set_lock_timeout

Using a larger lock timeout doesn't seem to solve the problem, it looks like 
the test
case is just waits forever.

Original comment by thomas.t...@gmail.com on 15 Aug 2009 at 10:45

[GoogleCodeExporter]

The next version will throw a 'lock timeout' exception instead.

Original comment by thomas.t...@gmail.com on 16 Aug 2009 at 10:21

• Changed title: Multi-version concurrency / wrong exception is thrown.
• Changed state: Accepted

[GoogleCodeExporter]

That's will be great!
LOCK_TIMEOUT solves the problem.

So, just switch it to more readable message and will be all okay =)
thanks

Original comment by a.kosenkov on 17 Aug 2009 at 1:41

[GoogleCodeExporter]

This should be fixed in version 1.1.118 (2009-09-04)

Original comment by thomas.t...@gmail.com on 4 Sep 2009 at 9:04

• Changed state: Fixed