Thanks Lukas,
That's fantastic. I'll be sure to give it a good work out :).
Cheers, Ryan
On 14/07/2012 10:37 PM, Lukas Eder wrote:
It will be a few months at my end.
OK. That raises chances of me getting this implemented before you :-)
... which I did. Implementing optimistic locking in jOOQ was quite simple.
Here are a couple of characteristics of this change:
- There are now UpdatableRecord.store() and storeLocked()
- The new name was chosen to indicate that client code may assume to
have "optimistically locked" the underlying record
- The only difference between the two is that storeLocked performs an
additional SELECT .. FOR UPDATE to check for changes. The "pessimistic
locking" FOR UPDATE clause is needed to avoid race conditions between
the SELECT and the subsequent UPDATE. FOR UPDATE may fail early, if
another transaction locked the database record in the mean time. This
is desired.
- SELECT .. FOR UPDATE is supported in most databases. In CUBRID and
SQL Server, jOOQ simulates it using JDBC cursors
(TYPE_SCROLL_SENSITIVE, CONCUR_UPDATABLE). I have recently blogged
about this here:
http://blog.jooq.org/2012/05/18/for-update-simulation-in-sql-server-and-cubrid/
- In SQLite, FOR UPDATE is omitted as there is no way to simulate it.
Race conditions can occur.
- If the selected record's values don't correspond to the original
values of the record being updated, a new (unchecked)
DataChangedException is thrown. It is also thrown if the underlying
database record has been deleted in the mean time.
So, this is implemented on GitHub master, and will be included in the
next jOOQ 2.5.0-SNAPSHOT version.
Cheers
Lukas
