@Transactional Annotation in Spring

Question 1

1. What Is @Transactional?
2. What does the annotation allow us to set?

Answer 1

1. We can use @Transactional to wrap a method in a database transaction.
2. It allows us to set propagation, isolation, timeout, read-only, and rollback conditions for our transaction. We can also specify the transaction manager.

Question 2

How does the @Transactional annotation work, how is it implemented?

Answer 2

Spring creates a proxy or manipulates the class byte-code to manage the creation, commit and rollback of the transaction.

Spring will wrap some transaction management code around the invocation @Transactional method called.

Question 3

What is Transaction Propagation?

Answer 3

Propagation defines our business logic’s transaction boundary. Spring manages to start and pause a transaction according to our propagation setting.

Spring calls TransactionManager::getTransaction to get or create a transaction according to the propagation

Question 4

What are the different types of Propagation?

Answer 4

REQUIRED Propagation
SUPPORTS Propagation
MANDATORY Propagation
NEVER Propagation
NOT_SUPPORTED Propagation
REQUIRES_NEW Propagation
NESTED Propagation

Question 5

Define REQUIRED Propagation for @Transactional

Answer 5

REQUIRED is the default propagation. Spring checks if there is an active transaction, and if nothing exists, it creates a new one. Otherwise, the business logic appends to the currently active transaction.

Question 6

Define SUPPORTS Propagation for @Transactional

Answer 6

ForSUPPORTS, Spring first checks if an active transaction exists. If a transaction exists, then the existing transaction will be used. If there isn’t a transaction, it is executed non-transactional.

Question 7

Define MANDATORY Propagation for @Transactional

Answer 7

When the propagation isMANDATORY, if there is an active transaction, then it will be used. If there isn’t an active transaction, then Spring throws an exception:

Question 8

Define NEVER Propagation for @Transactional

Answer 8

For transactional logic withNEVER propagation, Spring throws an exception if there’s an active transaction.

Question 9

Define NOT_SUPPORTED Propagation for @Transactional

Answer 9

If a current transaction exists, first Spring suspends it, and then the business logic is executed without a transaction.

Question 10

Define REQUIRES_NEW Propagation for @Transactional

Answer 10

When the propagation is REQUIRES_NEW, Spring suspends the current transaction if it exists, and then creates a new one:

Question 11

Define NESTED Propagation for @Transactional

Answer 11

For NESTED propagation, Spring checks if a transaction exists, and if so, it marks a save point. This means that if our business logic execution throws an exception, then the transaction rollbacks to this save point. If there’s no active transaction, it works like REQUIRED.

Question 12

What is Transaction Isolation

Answer 12

Transaction Isolation describes how changes applied by concurrent transactions are visible to each other.

Question 13

What are the different types of Transaction Isolation

Answer 13

• DEFAULT
• READ_UNCOMMITTED
• READ_COMMITTED
• REPEATABLE_READ
• SERIALIZABLE

Question 14

What could the concurrency side effects of a transaction be?

Answer 14

• Dirty read:read the uncommitted change of a concurrent transaction
• Nonrepeatable read: get different value on re-read of a row if a concurrent transaction updates the same row and commits
• Phantom read:get different rows after re-execution of a range query if another transaction adds or removes some rows in the range and commits

Question 15

@Transactional DEFAULT Isolation

Answer 15

The default isolation level isDEFAULT. As a result, when Spring creates a new transaction, the isolation level will be the default isolation of our RDBMS.

Question 16

@Transactional READ_UNCOMMITTED Isolation

Answer 16

READ_UNCOMMITTEDis the lowest isolation level and allows for the most concurrent access.

As a result, it suffers from all three mentioned concurrency side effects. A transaction with this isolation reads uncommitted data of other concurrent transactions. Also, both non-repeatable and phantom reads can happen. Thus we can get a different result on re-read of a row or re-execution of a range query.

Question 17

@Transactional READ_COMMITTED Isolation

Answer 17

READ_COMMITTED prevents dirty reads.

The rest of the concurrency side effects could still happen. So uncommitted changes in concurrent transactions have no impact on us, but if a transaction commits its changes, our result could change by re-querying.

READ_COMMITTEDis the default level with Postgres, SQL Server, and Oracle.

Question 18

@Transactional READ_COMMITTED Isolation

Answer 18

REPEATABLE_READ,prevents dirty, and non-repeatable reads. So we are not affected by uncommitted changes in concurrent transactions.
Moreover, it is the lowest required level to prevent the lost update.

Question 19

What does the “lost update” mean?

Answer 19

The lost update occurs when two or more concurrent transactions read and update the same row.