Why wouldn't it? Propagation NESTED
begins a transaction within the current one if one exists, and behaves like REQUIRED
otherwise. The javadocs state:
/**
* Support a current transaction; create a new one if none exists.
* Analogous to the EJB transaction attribute of the same name.
* <p>This is typically the default setting of a transaction definition,
* and typically defines a transaction synchronization scope.
*/
int PROPAGATION_REQUIRED = 0;
/**
* Execute within a nested transaction if a current transaction exists,
* behave like {@link #PROPAGATION_REQUIRED} else. There is no analogous
* feature in EJB.
* <p><b>NOTE:</b> Actual creation of a nested transaction will only work on
* specific transaction managers. Out of the box, this only applies to the JDBC
* {@link org.springframework.jdbc.datasource.DataSourceTransactionManager}
* when working on a JDBC 3.0 driver. Some JTA providers might support
* nested transactions as well.
* @see org.springframework.jdbc.datasource.DataSourceTransactionManager
*/
int PROPAGATION_NESTED = 6;
Of note is that NESTED
is truly only supported if your JDBC driver supports savepoints. This means:
No existing transaction
A (NESTED)
B (REQUIRED)
Would have the following behaviour:
begin; -- called prior to A but in A's
A.doSomething();
B.doSomethingThatCausesException()
rollback;
And
Existing transaction
A (NESTED)
B (REQUIRED)
Would have the following behaviour:
begin; -- called outside of the scope of A
savepoint A_savepoint
A.doSomething();
B.doSomethingThatCausesException();
rollback A_savepoint;
if your JDBC driver supports nested transactions. Otherwise, it would behave like the first scenario. See also this answer.
That said, I believe that savepoints are more trouble than they're worth and you will save yourself a lot of potential trouble if you're treating any of your database operations atomically.