Hi All-

I'm looking for an opinion on an appropriate locking strategy for an application we're building.

Basically, we are building a very high volume, real-time demand forecasting application. This application executes primarily through asynchronously generated events, and does result in semi-frequent concurrent updates of certain entities.

Our transactions are typically very brief, and usually consitent of us loading an object from the repository, updating some values, and quickly saving the object again. Although these transactions are brief, we still have some concurrency issues.

Given the nature of these short lived transactions, optimistic locking doesn't seem to be an effective option!?

Is the appropriate approach to use pessimistic locking? To completely lock the record as soon as we read it? Will other transactions block until the locking transaction completes?

Although I realize this is not typically the most scalable architecture, our concurrency issues are infrequent enough that I don't think it will cause an issue for us.

Any opinions are muich appreciated...

Thanks,
Brandon

Optimistic concurrency control is, if correctly used and and implemented, not something that is slow because it is better for long transactions. You can use it for very short transactions as well.

The difference is the risk of an exceptional state: With pessimistic locking in Hibernate, exclusive locks are set in the database. This is supported with the UPGRADE (and optional UPGRADE_NOWAIT) LockMode, Hibernate executes "select ... for update (nowait)" if the SQL dialect supports it.

If the same row is accessed in a concurrent transaction, a failure (exclusive lock) or wait occurs. This is a bottleneck, as all access to that row is executed serialized. This strategy prevents stale data for read operations and concurrent modification.

An optimistic approach uses a version number on the row in the database. This version number is increased everytime the row is updated, for example:

update EMP set ..., VERSION=2 where VERSION=1

The trick is simple: We know that the update has to fail if this statement returns 0 updated rows. This means there was no version 1 anymore, a concurrent transaction has already updated the row to version 2.

Information system applications use mostly an optimistic appraoch, financial/critical data might require pessimistic locking.

Thanks for that info - its very helpful. A couple of quick follow ups:

1) In the ref guide, chapter 17, it states that there are three approaches to optimistic locking. The nature of our transactions sound like case 3, where we load the object, modify the data, and quickly save the object. However, in this case, the version check is done manually, and that would seem not to work in our case. We are not updating an object accessed earlier in this case.

2) The case that would seem to work is case 1, "Long Sessions With Automatic Versioning." In this case, I'm assuming the trick you specified above would be applied, and the update would fail if an interim update from another thread had occurred. However, we are obviously not running "long sessions", so am I missing something?

3) Finally, if we use the approach in point 2 above, it would seem to absolutely guarantee data integrity, no? If so, what is the advantage of pessimistic locking? It is that with the approach above, some transactions might get rejected, while a pessimistic locking approach would ensure the transaction gets processed?

Thanks for your insight,
Brandon

1) Of course, what you then get is a) caching of that object at the first level, the Session and b) the transaction isolation of your JDBC connection (and database transaction). You don't need an additional optimistic concurrency check if you only have database transactions and no long running application transactions.

2) see above

3) A pessimistic lock guarantees data integrity. Hibernate doesn't lock anything in memory (only in the distributed second level cache), but uses the lock mechanism of the database. This is a good overview for Oracle, also check 17.5 of the reference documentation:

http://www.ebullen.demon.co.uk/tech_docs/ora_tune/locks.html

i think i have it now -- i couldn't find a clear description of how isolation modes worked...

I think I can get by with using a serializable isolation mode - or at least i'll try that first. I might even be able to get away with read_committed.

Interesting though, we're using DB2, and it's isolation modes map to the JDBC modes a little looser, it seems...meaning even in serializable mode, other processes can read the locked data..

Thanks for your help!

Of course, as "serialized access" does not imply an exclusive lock :)

For most applications we recommend the use of

(1) READ_COMMITTED
(2) versioning

SERIALIZABLE is pretty evil and you don't need it; phantom reads are really not such a big deal.

You get most of the nice stuff about REPEATABLE_READ by using versioning.


There is a section in the book where we discuss this fully.

Yes, I agree on version control. Just I wonder how to make update EMP set ..., VERSION=2 where VERSION=1 in hibernate and then return the affected rows?

You can't, Hibernate manage versioning entity by entity so

is done by hibernate itself under the cover.