How are the Spring @Transactional and the Hibernate @LockMode annotations related

Question

I wish to know the relation between transactions and locks.

To be more specific, how is Spring's @Transactional related to Hibernate's LockMode. https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.html. http://docs.spring.io/autorepo/docs/spring/4.2.x/spring-framework-reference/html/transaction.html

If I dont specify any lock while creating Session Object, and use @Transactional with readOnly as false, am I using Pessimistic Concurrenct Control.

It would be a great help, if anyone can tell me the relation between (Optimistic/Pessimistic) Concurrency Control and Transactions.

Thank you, Vivek

Answer 1

There is no direct relationship between @Transactional and @LockMode annotations.

@Transactional is used to mark the explicit boundaries of a RESOURCE_LOCAL or JTA transaction. The reason why you need it is that every database statement executes in a transactional context, and, if you don't set the transaction boundaries, you'll get one transaction per statement or auto-commit.

On the other hand, @LockModeType is for setting explicit locking options. If you don't set it, the implicit locking mechanisms will be used:

• Implicit locks are acquired on every modified row on both 2PL and MVCC database engines. Shared locks are acquired on read records on 2PL engines if you use Repeatable Read on Serializable.
• If you defined a @Version property, the implicit optimistic locking mechanism will be used.

So, @LockModeType is for setting locking options explicitly, and you can have the following options:

• LockModeType.PESSIMISTIC_READ
• LockModeType.PESSIMISTIC_WRITE

The PESSIMISTIC lock modes will always acquire a database lock on the table row that is associated with the locked entity.

There are also explicit optimistic lock strategies:

• LockModeType.OPTIMISTIC
• LockModeType.OPTIMISTIC_FORCE_INCREMENT
• LockModeType.PESSIMISTIC_FORCE_INCREMENT

The OPTIMISTIC lock modes are meant to give you a way of bumping up an entity version even if the entity hasn't changed in the currently running Persistence Context. This is a very useful mechanism when you need to coordinate multiple child entities using their parent entity version.

There are lots of examples in the links that I provided in this answer, so take your time, read them all, and you'll understand all these concepts in greater detail.