|
From: Alef A. <al...@jt...> - 2004-06-19 13:56:23
|
Good stuff Juergen.
It would be nice to have those kind of features tested regularly. =
Unfortunately I still haven't managed to setup an Oracle instance on the =
Linux box we've got here. I've been running into problems with Oracle =
and the distro we're using (RedHat ES 3) several times.
Alef
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of j=FCrgen h=F6ller [werk3AT]
> Sent: Saturday, June 19, 2004 12:16 PM
> To: spr...@li...
> Subject: [Springframework-developer] Nested transactions
>=20
> Thomas, Alef, Colin, everybody,
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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?
>=20
> 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.
>=20
> DataSource ds =3D ...;
> final PlatformTransactionManager tm =3D new
> DataSourceTransactionManager(ds);
> final JdbcTemplate jt =3D new JdbcTemplate(ds);
>=20
> TransactionTemplate tt1 =3D new TransactionTemplate(tm);
> =
tt1.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
> tt1.execute(new TransactionCallbackWithoutResult() {
> protected void doInTransactionWithoutResult(TransactionStatus =
status)
> {
> jt.update("first update statement");
>=20
> TransactionTemplate tt1 =3D new TransactionTemplate(tm);
>=20
> tt1.setPropagationBehavior(TransactionDefinition.PROPAGATION_NESTED);
> tt1.execute(new TransactionCallbackWithoutResult() {
> protected void doInTransactionWithoutResult(TransactionStatus
> status) {
> jt.update("second update statement");
> status.setRollbackOnly();
> }
> });
> }
> });
>=20
> An example for the same effect via manual savepoint management:
>=20
> TransactionTemplate tt1 =3D new TransactionTemplate(tm);
> =
tt1.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
> tt1.execute(new TransactionCallbackWithoutResult() {
> protected void doInTransactionWithoutResult(TransactionStatus =
status)
> {
> jt.update("first update statement");
>=20
> Object savepoint =3D status.createSavepoint();
> jt.update("second update statement");
> status.rollbackToSavepoint(savepoint);
>=20
> }
> });
>=20
> Juergen
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
|
|
From: Norris, T. <tys...@be...> - 2004-06-19 16:30:18
|
Hi Juergen -=20
How does this differ from the REQUIRES_NEW propagation?
Thanks
Tyson
-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Saturday, June 19, 2004 3:02 AM
To: spr...@li...
Subject: [Springframework-developer] Nested transactions
Thomas, Alef, Colin, everybody,
=20
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.
=20
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.
=20
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.
=20
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.
=20
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?
=20
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.
=20
DataSource ds =3D ...;
final PlatformTransactionManager tm =3D new =
DataSourceTransactionManager(ds);
final JdbcTemplate jt =3D new JdbcTemplate(ds);
TransactionTemplate tt1 =3D new TransactionTemplate(tm);
=
tt1.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
tt1.execute(new TransactionCallbackWithoutResult() {
protected void doInTransactionWithoutResult(TransactionStatus =
status) {
jt.update("first update statement");
TransactionTemplate tt1 =3D 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:
=20
TransactionTemplate tt1 =3D new TransactionTemplate(tm);
=
tt1.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
tt1.execute(new TransactionCallbackWithoutResult() {
protected void doInTransactionWithoutResult(TransactionStatus =
status) {
jt.update("first update statement");
Object savepoint =3D status.createSavepoint();
jt.update("second update statement");
status.rollbackToSavepoint(savepoint);
}
});
=20
Juergen
=20
-------------------------------------------------------
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
|
|
From: Colin S. <col...@ex...> - 2004-06-19 19:22:53
|
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
>
>
|
|
From: Norris, T. <tys...@be...> - 2004-06-19 22:32:51
|
Thanks Colin. It all makes sense now.
Thanks
Tyson
-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]=20
Sent: Saturday, June 19, 2004 12:27 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Nested transactions
Tyson,
REQUIRES_NEW actually just suspends the current transaction, and then=20
starts a new, unrelated transaction transaction to run the contained=20
code in. If you commit the inner, new transaction, then rollback the=20
outer, the inner transaciton will still be committed, as they are=20
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=20
essentially the same as the requires new support in the EJB spec.
PROPOGATION_NESTED means that a new nested, or child transaction is=20
created inside the outer one. If you commit the child (nested)=20
transaction, but roll back the outer, parent transaction, the effects of =
the child are also rolled back. JTA (and EJB) doesn't actually support=20
nested transactions. You essentially need a DB and JDBC driver, such as=20
Oracle, that does, which you can use directly.
Hope this clears things up,
Colin
Norris, Tyson wrote:
>Hi Juergen -=20
>How does this differ from the REQUIRES_NEW propagation?
>Thanks
>Tyson
>
>-----Original Message-----
>From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
>Sent: Saturday, June 19, 2004 3:02 AM
>To: spr...@li...
>Subject: [Springframework-developer] Nested transactions
>
>Thomas, Alef, Colin, everybody,
>=20
>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.
>=20
>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.
>=20
>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.
>=20
>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.
>=20
>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?
>=20
>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.
>=20
> DataSource ds =3D ...;
> final PlatformTransactionManager tm =3D new =
DataSourceTransactionManager(ds);
> final JdbcTemplate jt =3D new JdbcTemplate(ds);
>
> TransactionTemplate tt1 =3D new TransactionTemplate(tm);
> =
tt1.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
> tt1.execute(new TransactionCallbackWithoutResult() {
> protected void doInTransactionWithoutResult(TransactionStatus =
status) {
> jt.update("first update statement");
>
> TransactionTemplate tt1 =3D 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:
>=20
> TransactionTemplate tt1 =3D new TransactionTemplate(tm);
> =
tt1.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
> tt1.execute(new TransactionCallbackWithoutResult() {
> protected void doInTransactionWithoutResult(TransactionStatus =
status) {
> jt.update("first update statement");
>
> Object savepoint =3D status.createSavepoint();
> jt.update("second update statement");
> status.rollbackToSavepoint(savepoint);
>
> }
> });
>=20
>Juergen
>=20
>
>
>-------------------------------------------------------
>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
> =20
>
-------------------------------------------------------
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
|
|
From: <jue...@we...> - 2004-06-20 00:30:26
|
I read that in the Oracle driver manual; that's why I coded the =
releaseSavepoint call with a try/catch block around it :-) Basically, =
Oracle doesn't seem to support eager releasing of a savepoint but just =
auto-release on transaction completion. They could have implemented =
releaseSavepoint as no-op, but rather decided to throw a SQLException...
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Thomas Risberg
Gesendet: Sa 19.06.2004 16:10
An: spr...@li...
Betreff: Re: [Springframework-developer] Nested transactions
Ooops, the 10g driver complains about the releaseSavepoint as well -
must have missed that in the log earlier. Still works though.
Thomas
Thomas Risberg wrote:
> Yes, it does work against a 9i db using both 9i (9.2.0.3) and 10g
> drivers. Nice job coding in the "dark" :-)
>
> 9i driver complains about not supporting "releaseSavepoint"
> (java.sql.SQLException: Unsupported feature), but it still seems to
> work. 10g driver had no problems at all.
>
> PostgreSQL (7.4) failed nicely. No support for savepoints.
>
> MS SQL Server (driver 2.2.0029) errored out with a
> "java.lang.AbstractMethodError". It must only support JDBC 2 --
> supportsSavepoints was added in JDBC 3. I added a try/catch for that
> to provide a nicer error.
>
> Any way you can get this to work in a managed environment with JTA :-)
>
> Thomas
>
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
>> 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 =3D ...;
>> final PlatformTransactionManager tm =3D new
>> DataSourceTransactionManager(ds);
>> final JdbcTemplate jt =3D new JdbcTemplate(ds);
>>
>> TransactionTemplate tt1 =3D new TransactionTemplate(tm);
>> =
tt1.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
>> tt1.execute(new TransactionCallbackWithoutResult() {
>> protected void doInTransactionWithoutResult(TransactionStatus
>> status) {
>> jt.update("first update statement");
>>
>> TransactionTemplate tt1 =3D new TransactionTemplate(tm);
>> =20
>> 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 =3D new TransactionTemplate(tm);
>> =
tt1.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
>> tt1.execute(new TransactionCallbackWithoutResult() {
>> protected void doInTransactionWithoutResult(TransactionStatus
>> status) {
>> jt.update("first update statement");
>>
>> Object savepoint =3D 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
>>
>>
>>
>>=20
>>
>
>
>
> -------------------------------------------------------
> 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
|