CODEWITHSUNDEEP
javaspringhibernatetransactionslocking
vivek4348
vivek4348

Reputation: 497

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

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

Upvotes: 19

Views: 33318

Answers (2)

Vlad Mihalcea
Vlad Mihalcea

Reputation: 154030

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:

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:

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.

Upvotes: 25

ck1
ck1

Reputation: 5443

Spring's @Transactional and Hibernate's LockMode class are different.

Spring Transaction Management

@Transactional is a Spring annotation for declarative transaction management, i.e. defining what SQL statements are executed together inside of a database transaction. Using the readOnly attribute allows Spring to throw an exception if you attempt to insert rows inside of a read-only transaction, for example.

With respect to locking, however, you'll most likely be using a read/write (readOnly = false) transaction, because you'll be attempting to modify data.

Pessimistic Locking

Hibernate's LockMode is used for pessimistic locking, e.g. LockMode.UPGRADE actually executes a SELECT...FOR UPDATE statement, and locks the row in the database corresponding to the entity.

Pessimistic locking assumes that concurrent transactions will conflict with each other, and requires resources to be locked after they are read and only unlocked after the application has finished using the data.

Optimistic Locking

Optimistic concurrency control in Hibernate typically uses a version or timestamp column in the database. The idea here is that if multiple transactions attempt to modify a row concurrently, all but the first committed transaction will detect that the version number has changed and perform a rollback.

Optimistic locking assumes that multiple transactions can complete without affecting each other, and that therefore transactions can proceed without locking the data resources that they affect. Before committing, each transaction verifies that no other transaction has modified its data. If the check reveals conflicting modifications, the committing transaction rolls back.

Quotes above are from: https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.html

Upvotes: 5

Related Questions