Optimistic Locking in Hibernate by default

Question

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 appr

Answer 1

@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.

Answer 2

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.