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
|
