What is the relation between Spring @Transactional and Spring @Lock annotation?

Question

I found that the @Transactional is used to ensure transaction on repository method or on a service method.
@Lock is used on repository method to ensure locking of entity to provide isolation.

Some questions are raised in my mind:

1. What are major difference/relations in these two annotations ?
2. When to use @Transactional and when to use @Lock ?
3. Is @Lock useful in distributed database system to provide data concurrency and consistency ?

Answer 1

Transactional: Whenever you put @Transactional annotation, it enables transactional behavior which qualifies ACID properties

ACID: ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties of database transactions intended to guarantee the validity even in the event of errors.

Atomic Guarantees that all operations in a transaction are treated as a single “unit”, which either succeeds completely or fails completely.

Consistent Ensures that a transaction can only bring the database from one valid state to another by preventing data corruption.

Isolation Determines how and when changes made by one transaction become visible to the other. Serializable and Snapshot Isolation are the top 2 isolation levels from a strictness standpoint.

Durable Ensures that the results of the transaction are permanently stored in the system. The modifications must persist even in case of power loss or system failures.

---

Lock: It should not be confused with transactional,@Lock enables locking behavior during a transaction

JPA has two main lock types defined.

1. Pessimistic Locking
2. Optimistic Locking

If you want to know more about Pessimistic and Obtimistic locking you can explore the internet, below is explanation from Baeldung,

Pessimistic Locking When we are using Pessimistic Locking in a transaction and access an entity, it will be locked immediately. The transaction releases the lock either by committing or rolling back the transaction.

Optimistic Locking In Optimistic Locking, the transaction doesn't lock the entity immediately. Instead, the transaction commonly saves the entity's state with a version number assigned to it.

When we try to update the entity's state in a different transaction, the transaction compares the saved version number with the existing version number during an update.

At this point, if the version number differs, it means that the entity can't be modified. If there is an active transaction then that transaction will be rolled back and the underlying JPA implementation will throw an OptimisticLockException.

Apart from the version number approach, we can use other approaches such as timestamps, hash value computation, or serialized checksum, depending on which approach is the most suitable for our current development context.

There are also other lock types available in spring

• NONE: No lock.
• OPTIMISTIC: Optimistic lock.
• OPTIMISTIC_FORCE_INCREMENT: Optimistic lock, with version update.
• PESSIMISTIC_FORCE_INCREMENT: Pessimistic write lock, with version update
• PESSIMISTIC_READ: Pessimistic read lock.
• PESSIMISTIC_WRITE: Pessimistic write lock.
• READ: Synonymous with OPTIMISTIC.
• WRITE: Synonymous with OPTIMISTIC_FORCE_INCREMENT.

---

Now answer to your questions

1. What are the major differences/relations in these two annotations?

You will understand after reading above

2. When to use @Transactional and when to use @Lock?

If you want transactional behavior then add @transactional and if your usecase requires locking and as per use case use appropriate locking

3. Is @Lock useful in the distributed database system to provide data concurrency and consistency?

The two main tools we use to cope with concurrency are database transactions and distributed locks. These two are not interchangeable. You can't use a transaction when you need a lock. You can't use a lock when you need a transaction. source