Re: [Springframework-developer] Ready for 1.0 RC1

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

There _is_ actually a pretty big use case for this, supporting existing 
code which wants to use this type of  mechanism.

For example, we currently use OSWorkflow with the EJB implementation. We 
want to move to the Hibernate workflow store, but would have to create 
our own Spring-based transactional workflow to wrap around that. This 
needs to support a setRollbackOnly mechanism, same as the existing impl. 
(based on ejb), and the caller doesn't expect an exception at that 
point, so it's not like the impl. could just throw an exception. 
Anyways, we can just use the status off the template, so that's fine, 
but other people might do the same thing as Alef (try to work off the 
transactionmanager). I got confused myself; when I was looking at the 
impl. last night I saw for a few of the propogation cases (not 
supported, and new) that it created a new status and suspended the 
existing trans., but I figured for the null case with the default 
definition object being created, and joining in the existing 
transaction, with no new synchronization, that he was ok. Of course that 
doesn't make any sense, there is a whole new status object being created...

We should probably change the javadocs for PlatformTransactionManager to 
clarify that getTransaction is not for this use case...



jürgen höller [werk3AT] wrote:

>Alef,
> 
>What you're doing here is getting a *new* TransactionStatus for a new sub-transaction back: A sub-transaction needs to be committed or rollbacked (via mgr.commit/rollback) to be effective.
> 
>What you intend is to mark the *current* TransactionStatus rollback-only: with TransactionTemplate, you can use the passed-in TransactionStatus; with AOP, TransactionInterceptor.currentTransactionStatus().
> 
>In general, I see hardly any use cases for rolling back without throwing an exception anyway. If you want to roll back on checked exception, simply specify those in the transaction attributes, e.g. "-MyCheckedException".
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Alef Arendsen
>Gesendet: Do 05.02.2004 00:27
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Ready for 1.0 RC1
>
>
>
>There's an issue that just came up with the TransactionManager. I
>haven't spend enough time on it to fully figure it out, but before I dig
>into it further, maybe you guys can give an opinion:
>
>When using a DataSourceTransactionManager, in a bean I'm asking the
>applicationcontext for the transactionmanager. After calling
>setRollbackOnly() is doesn't rollback. I've reproduced this using
>petclinic, by implementing ApplicationContextAware in AbstractJdbcClinic
>and in one of the store*** methods calling:
>
>PlatformTransactionManager mgr =
>        (PlatformTransactionManager)appCtx.getBean(
>        "transactionManager");
>// does this give me the current transaction???
>mgr.getTransaction(null).setRollbackOnly();
>
>AFAIK this should result in a rollback, shouldn't it...
>
>Thanx,
>
>Alef
>
>P.s. we're doing this because of some legacy code that needs to rollback
>as well. We can't reimplement it right now...
>  
>