Re: [Springframework-developer] PROPOGATION_REQUIRESNEW

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

I guess whether it's worth it depends on the usage scenario, to some=20
extent. If you think about people using something like JBoss or=20
WebLogic, who want to drop EJBs, but still want the app server because=20
they use JMS or for some other reason, they would probably prefer to=20
keep using the app server's transaction manager. So these people would=20
not be helped at all.

On the other hand, if somebody is willing to work in a lighter weight=20
environment (TomCat with JOTM or something of the sort), then it would=20
be of some use.

Unfortunately I don't feel comfortable messing around in that particular=20
code in Spring (all I've ever done is step through it), so it would have=20
to be something you do when/if you have the time and inclination.

Actually I should take a look and see if JBoss and WebLogic support any=20
sort of proprietary access to the transaction manager. If so, this stuff=20
could at least be pluggable...


j=FCrgen h=F6ller [werk3AT] wrote:

>Colin,
>=20
>Good point - I've been wondering about this myself repeatedly. As you sa=
y, it seems that you can just implement REQUIRESNEW with knowledge about =
the internals of the transaction manager, as the JTA API does not offer a=
ny means to suspend a transaction. So that seems to stay a unique EJB fea=
ture, unfortunately - except maybe for specific transaction managers of s=
pecific 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 JdoTransac=
tionManager. It wouldn't be too hard, actually: basically unbind the curr=
ent transaction from the thread, store it in the backyard of the new tran=
saction 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 o=
f hours; if I find the time, I might implement this. Of course, not for J=
taTransactionManager: that would require server-specific subclasses, and =
more importantly, figuring out the proprietary API.
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n 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
> =20
>