db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacopo Cappellato <jacopo.cappell...@gmail.com>
Subject Unexpected behavior for concurrent selection of an uncommitted record inserted in a different thread
Date Fri, 07 Feb 2014 17:59:06 GMT
Hi all!

While I was writing some unit tests for the Apache OFBiz project (that by default runs on
Derby) I noticed a behavior of Derby that I didn't expect and I would love to get your opinion.
Here is my use case:

* Derby
* there are two concurrent transactions T1 and T2
* isolation level is "Read Committed"
* in transaction T1 a record with primary key 123 is inserted in a table; then other long
running tasks are executed (i.e. the transaction is not immediately committed)
* in the meantime T2 attempts to select from the same table the record with primary key 123

Behavior: T2 blocks on the select statement waiting for transaction T1 to release the write
lock; this can cause a lock wait timeout
Expected behavior: since T1 is not committed, T2 should not be able to select the record;
I was expecting that the select statement in T2 would return an empty result set rather than
blocking waiting for the lock held by T1 to be released; in fact this is what we get with
MySQL and Postgres.

What do you think?


Jacopo Cappellato
View raw message