Re: [Springframework-developer] Nested transactions

[Colin S. <col...@ex...>]

Tyson,

REQUIRES_NEW actually just suspends the current transaction, and then 
starts a new, unrelated transaction transaction to run the contained 
code in. If you commit the inner, new transaction, then rollback the 
outer, the inner transaciton will still be committed, as they are 
unrelated. This should work properly inside any JTA environment (as long 
as spring can get at the jta transaction manager) and the model is also 
essentially the same as the requires new support in the EJB spec.

PROPOGATION_NESTED means that a new nested, or child transaction is 
created inside the outer one. If you commit the child (nested) 
transaction, but roll back the outer, parent transaction, the effects of 
the child are also rolled back. JTA (and EJB) doesn't actually support 
nested transactions. You essentially need a DB and JDBC driver, such as 
Oracle, that does, which you can use directly.

Hope this clears things up,
Colin

Norris, Tyson wrote:

>Hi Juergen - 
>How does this differ from the REQUIRES_NEW propagation?
>Thanks
>Tyson
>
>-----Original Message-----
>From: jürgen höller [werk3AT] [mailto:jue...@we...] 
>Sent: Saturday, June 19, 2004 3:02 AM
>To: spr...@li...
>Subject: [Springframework-developer] Nested transactions
>
>Thomas, Alef, Colin, everybody,
> 
>Motivated by Rod, I've added support for nested transactions to our transaction infrastructure, via the new propagation behavior PROPAGATION_NESTED. The transaction manager needs to open a true nested transaction which can be rolled back individually while still being able to continue with the surrounding transaction.
> 
>Furthermore, application code can also use custom savepoints: The TransactionStatus interface now has a SavepointManager superinterface, which provides generic means to create savepoints and roll back to them. This is only intended for advanced needs where the declarative nested transaction model is not sufficient.
> 
>DataSourceTransactionManager implements nested transaction support via JDBC 3.0 Savepoints: basically, create a Savepoint on nested transaction begin, release it on nested transaction commit, roll back to it on nested transaction rollback. Of course, DataSourceTransactionManager is still compatible with JDBC 2.0 if not using nested transactions.
> 
>HibernateTransactionManager and JdoTransactionManager offer support for JDBC 3.0 Savepoints too, but it's deactivated by default there: Savepoints are just able to roll back the underlying JDBC Connection, not the Session respectively PersistenceManager with its object cache. Savepoints are still useful for JDBC access code that participates in a Hibernate/JDO transaction, though, when used with care.
> 
>All of this is already fully covered by unit tests. Unfortunately, I don't have a database with savepoint support available here, i.e. no Oracle; so I've just been able to test that it fails nicely against MySQL (on JDK 1.4 and 1.3). Thomas, do you have a chance to test this against a live database?
> 
>An example for how PROPAGATION_NESTED is supposed to work. Note that the nested transaction sets the rollback-only flag: This should just cause a rollback of the second update statement but still allow the surrounding transaction to commit the first update statement.
> 
>  DataSource ds = ...;
>  final PlatformTransactionManager tm = new DataSourceTransactionManager(ds);
>  final JdbcTemplate jt = new JdbcTemplate(ds);
>
>  TransactionTemplate tt1 = new TransactionTemplate(tm);
>  tt1.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
>  tt1.execute(new TransactionCallbackWithoutResult() {
>    protected void doInTransactionWithoutResult(TransactionStatus status) {
>      jt.update("first update statement");
>
>      TransactionTemplate tt1 = new TransactionTemplate(tm);
>      tt1.setPropagationBehavior(TransactionDefinition.PROPAGATION_NESTED);
>      tt1.execute(new TransactionCallbackWithoutResult() {
>        protected void doInTransactionWithoutResult(TransactionStatus status) {
>          jt.update("second update statement");
>          status.setRollbackOnly();
>        }
>      });
>    }
>  });
>
>An example for the same effect via manual savepoint management:
> 
>  TransactionTemplate tt1 = new TransactionTemplate(tm);
>  tt1.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
>  tt1.execute(new TransactionCallbackWithoutResult() {
>    protected void doInTransactionWithoutResult(TransactionStatus status) {
>      jt.update("first update statement");
>
>      Object savepoint = status.createSavepoint();
>      jt.update("second update statement");
>      status.rollbackToSavepoint(savepoint);
>
>    }
>  });
> 
>Juergen
> 
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
>REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
>REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>