Menu
I have one question about optimistic locking in Hibernate. I am trying to go deep inside optimistic locking with Hibernate, but I have one doubt. Hibernate uses version approach (integer or timestamp) to implement optimistic locking. To configure you can use @Version annotation (or xml configuration) and create a version attribute. The other option is configuring without versioning using optimistic-lock="all" attribute.
My question is in case that you don not define any versioning attribute and also you do not specify an optimistic-lock attribute, which strategy uses Hibernate in this cases? Pessimistc Locking I am pretty sure that no, so I suppose that is optimistic locking but don't know how.
Thank you very much for your attention.
458
We've learned that optimistic locking is enabled for versioned entities by default. However, there are several ways of requesting it explicitly by using various lock mode types. We should also remember that each time there are conflicting updates on entities, we should expect an OptimisticLockException.
As seen in previous article, Hibernate, by default, follows the JDBC approach of relying on DBMS default transaction isolation level allowing to override it for a specific transaction if required.
Optimist lock in hibernate checks VERSION of ROW. If Alice product has the same version as she fetched it will save to db. If alice wanted to save product but version is not the same as she fetched will throw exception.
If an object is requested with this lock mode, a READ lock will be obtained if it is necessary to actually read the state from the database, rather than pull it from a cache. This is the "default" lock mode.
If you don't configure Hibernate to use optimistic locking, it uses no locking at all. So, in this case last update always wins.
Just to make it clear, note that Hibernate optimistic locking is completely different from DBMS transaction isolation. Hibernate optimistic locking only works in situation when you load object in one transaction, modify it and save it later in another transaction. In this case optimistic locking ensures that some other transaction haven't changed that object in the database in between. However, optimistic locking doesn't affect isolation of concurrent transactions - so, locks (optimistic or pessimistic) used by DBMS internally to implement transaction isolation still works, no matter whether Hibernate locking is enabled or not.
69
@axtavt, you right, but question about how hibernate implement optimistic locking without @Version column.
Today four OptimisticLockType options available:
/**
* Perform no optimistic locking.
*/
NONE,
/**
* Perform optimistic locking using a dedicated version column.
*
* @see javax.persistence.Version
*/
VERSION,
/**
* Perform optimistic locking based on *dirty* fields as part of an expanded WHERE clause restriction for the
* UPDATE/DELETE SQL statement.
*/
DIRTY,
/**
* Perform optimistic locking based on *all* fields as part of an expanded WHERE clause restriction for the
* UPDATE/DELETE SQL statement.
*/
ALL
I think this is enough to answer the original question.
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
