Re: [Springframework-developer] Retrieving the current transaction

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

jürgen höller [werk3AT] wrote:

>I've added the following static utility method "setCurrentTransactionRollbackOnly" (not committed yet), rolling back any kind of current transaction. PROPAGATION_MANDATORY will cause an exception to be thrown if there is no existing transaction. Note that the "rollback" call will just mark the surrounding transaction rollback-only here.
> 
>public abstract class PlatformTransactionManagerUtils {
> 
> public static void setCurrentTransactionRollbackOnly(PlatformTransactionManager ptm) throws TransactionException {
>  TransactionDefinition definition = new DefaultTransactionDefinition(TransactionDefinition.PROPAGATION_MANDATORY);
>  TransactionStatus status = ptm.getTransaction(definition);
>  ptm.rollback(status);
> }
> 
>}
>
>This isn't really something that TransactionTemplate should care about: It's a general option for any kind of transaction demarcation.
> 
>An alternative would be to have a CurrentTransactionStatus ThreadLocal somewhere that AbstractPlatformTransactionManager would have to expose a returned TransactionStatus instance to (for any kind of transaction demarcation). Any opinions on the above PlatformTransactionManagerUtils vs such a CurrentTransactionStatus?
> 
>Juergen
>  
>
I presume you put this method in a separate class, instead of being part 
of the PlatformTransactionManager interface, so it would work with any 
PlatformTransactionManager implementation?

The advantage of the threadlocal vs. this implementation is that 
obviously with this impl., a user like a service or mapper object will 
now have to have an instance of the PlatformTransactionManager to feed 
to the method, whereas with the threadlocal it's accessible from 
anywhere. Same argument applies w/regards to doing it directly off 
PlatformTransactionManager, or off TransactionTemplate.

The advantage of doing it via a method on TransactionTemplate, or even 
PlatformTransactionManager, is that somebody unit testing the service 
object or mapper code using this functionality can properly feed in a 
mock implementation. As such, even if it ultimately goes to a static 
method like this, or ends up using quasi-static data like the 
ThreadLocal, I think it's worth it to have some interface that the 
actual user calls the method on, instead of a directly using a static 
method...

Regards.
Colin