Differences between requires_new and nested propag

Question

I can't understand the behavior difference between the PROPAGATION_REQUIRES_NEW and PROPAGATION_NESTED propagation policies. It seems to me that in both cases, the current process is rollbacked but not the whole transaction. Any clue?

Answer 1

See this link: PROPAGATION_NESTED versus PROPAGATION_REQUIRES_NEW? Juergen Hoeller explain it very well

PROPAGATION_REQUIRES_NEW starts a new, independent "inner" transaction for the given scope. This transaction will be committed or rolled back completely independent from the outer transaction, having its own isolation scope, its own set of locks, etc. The outer transaction will get suspended at the beginning of the inner one, and resumed once the inner one has completed. ...

PROPAGATION_NESTED on the other hand starts a "nested" transaction, which is a true subtransaction of the existing one. What will happen is that a savepoint will be taken at the start of the nested transaction. Íf the nested transaction fails, we will roll back to that savepoint. The nested transaction is part of of the outer transaction, so it will only be committed at the end of of the outer transaction. ...

Answer 2

Please find the difference

1.) Use of NESTED Transaction

Execute within a nested transaction if a current transaction exists, behave like PROPAGATION_REQUIRED else. Nested transaction is supporting by Spring

2.)Use of REQUIRED Transaction Support a current transaction, create a new one if none exists. . It means for banking domain like withdraw,deposit, update the transaction

3.) Use of REQUIRES_NEW Transaction Create a new transaction, and suspend the current transaction if one exists.

Answer 3

PROPAGATION_REQUIRES_NEW : uses a completely independent transaction for each affected transaction scope. In that case, the underlying physical transactions are different and hence can commit or roll back independently, with an outer transaction not affected by an inner transaction's rollback status.

PROPAGATION_NESTED : uses a single physical transaction with multiple savepoints that it can roll back to. Such partial rollbacks allow an inner transaction scope to trigger a rollback for its scope, with the outer transaction being able to continue the physical transaction despite some operations having been rolled back. This setting is typically mapped onto JDBC savepoints, so will only work with JDBC resource transactions.

check spring documentation