Propagation
REQUIRED (default) – Spring will create a transaction if there is no transaction in progress or use the existing one if there is one in progress.
REQUIRES_NEW – Spring suspends the current transaction if it exists, and then creates a new one
MANDATORY – If there is an active transaction, then it will be used. If there isn’t an active transaction, then Spring throws an exception.
NEVER – Spring throws an exception if there’s an active transaction.
SUPPORTS – 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.
NOT_SUPPORTED – If a current transaction exists, first Spring suspends it, and then the business logic is executed without a transaction.
NESTED – 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.
Isolation
The isolation attribute value defines how data modified in a transaction affects other simultaneous transactions. As a general idea, transactions should be isolated. A transaction should not be able to access changes from another uncommitted transaction. There are four levels of isolation at the RDBMS level, and every database management system supports them differently.
DEFAULT: The default isolation level of the DBMS.
READ_UNCOMMITED: Data changed by a transaction can be read by a different transaction while the first one is not yet committed, also known as dirty reads. Dirty reads are possible at this isolation level.
READ_COMMITTED: Dirty reads are not possible when a transaction is used with this isolation level. This is the default strategy for most databases. But a different phenomenon could happen here:
non-repeatable read: when the same query is executed multiple times, different results might be obtained. (For example, a person is extracted repeatedly within the same transaction. In parallel,
a different transaction edits the person and commits. If the first transaction has this isolation level, it will return the person with the new properties after the second transaction is committed.)
REPEATABLE_READ: This level of isolation does not allow dirty reads, and repeatedly querying a table row in the same transaction will always return the same result, even if a different transaction has changed the data and committed while the reading occurs. The process of reading the same row multiple times in the context of a transaction and always getting the same result is called repeatable read. But, at this level, phantom reads are still possible. A phantom read happens when in the course of a transaction, the execution of identical queries leads to different result sets returned.
SERIALIZABLE: This is the most restrictive isolation level, since transaction are executed in a serialized way. So no dirty reads, no repeatable reads, and no phantom reads are possible.
Problems
Dirty reads – Data changed by a transaction can be read by a different transaction while the first one is not yet committed.
Repeatable reads – when the same query is executed multiple times, different results might be obtained.
Phantom reads – when in the course of a transaction, the execution of identical queries leads to different result sets returned.
| Dirty Reads | Repeatable Reads | Phantom Reads | |
| READ_UNCOMMITED | |||
| READ_COMMITED | X | ||
| REPEATABLE_READ | X | X | |
| SERIALIZABLE | X | X | X |
https://www.baeldung.com/spring-transactional-propagation-isolation