Re: [Springframework-developer] PROPOGATION_REQUIRESNEW

[<jue...@we...>]

Colin,
=20
Good point - I've been wondering about this myself repeatedly. As you =
say, it seems that you can just implement REQUIRESNEW with knowledge =
about the internals of the transaction manager, as the JTA API does not =
offer any means to suspend a transaction. So that seems to stay a unique =
EJB feature, unfortunately - except maybe for specific transaction =
managers of specific J2EE servers where someone figures out how to =
trigger this.
=20
We *could* implement this for Spring's own transaction managers, namely =
DataSourceTransactionManager, HibernateTransactionManager, and =
JdoTransactionManager. It wouldn't be too hard, actually: basically =
unbind the current transaction from the thread, store it in the backyard =
of the new transaction object, bind the new transaction to the thread. =
On commit of the new transaction, rebind the original transaction to the =
thread.
=20
Do you think that would be worthwhile? It's really just about a couple =
of hours; if I find the time, I might implement this. Of course, not for =
JtaTransactionManager: that would require server-specific subclasses, =
and more importantly, figuring out the proprietary API.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: So 11.01.2004 21:46
An: spr...@li...
Betreff: [Springframework-developer] PROPOGATION_REQUIRESNEW



What would be involved in supporting PROPOGATION_REQUIRESNEW, similar to
an EJB setting of RequiresNew?

While J2EE doesn't support nested transactions for EJBs (although
JTS/JTA may or may not) EJBs do support the RequiresNew setting, which
is supposed to 'suspend' the current transaction and start a new one,
the termination of which will either commit or rollback the new
transaction, without affecting the enclosing one.

Now if you are dealing with a UserTransaction object, and call begin(),
my understanding is that you will either get a real nested transaction
if the transaction manager supports nested transactions, or an exception
if it doesn't (which presumably most transaction managers in most
containers will not).

So I am curious how EJB containers implement RequiresNew. I presume that
as of the RequiresNew, they associate an entirely new transaction
manager for the purposes of that EJB/thread. As such, it would be
impossible for Spring to do the same thing when working with a JTA
UserTransaction from JNDI, since it is not the container actually
managing the transaction manager. I presume if Spring itself were to
completely manage transactions (ie it was the transaction manager) then
it would not be an issue to simulate the EJB behaviour.

Part of my reason for bringing up this topic is that people converting
code from EJBs often have declarative transactions with RequiresNew. Now
a lot of the time it makes no difference if they switch to Requires (and
in fact they used Requires vs. RequiresNew due to the restrictive EJB
level locking implemented by most containers), but some of the time, for
handling things like logging, etc., RequiresNew would be desirable.

Anybody care to comment?

Regards
Colin





-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer