|
From: <jue...@we...> - 2004-02-08 11:32:07
|
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.
=20
public abstract class PlatformTransactionManagerUtils {
=20
public static void =
setCurrentTransactionRollbackOnly(PlatformTransactionManager ptm) throws =
TransactionException {
TransactionDefinition definition =3D new =
DefaultTransactionDefinition(TransactionDefinition.PROPAGATION_MANDATORY)=
;
TransactionStatus status =3D ptm.getTransaction(definition);
ptm.rollback(status);
}
=20
}
This isn't really something that TransactionTemplate should care about: =
It's a general option for any kind of transaction demarcation.
=20
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?
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Fr 06.02.2004 22:55
An: spr...@li...
Betreff: [Springframework-developer] Re: [Springframework-user] =
Retrieving the current transaction
Guys, is it worth adding a convenience method for setRollbackOnly, to
TransactionTemplate, something like this? It's a lot more intuitive than
the anonymous class method below.
public void setRollbackOnly() throws TransactionException {
TransactionStatus status =3D =
this.transactionManager.getTransaction(this);
if (status.isNew)
throw new TransactionUsageException("unable to join existing
transaction. Possible incorrect TransactionTemplate configuration");
status.setRollbackOnly();
this.transactionManager.commit(status);
}
Regards,
Colin
Colin Sampaleanu wrote:
> This is obviously only going to work if a TransactionInterceptor is
> involved. Alternately, if you want to do this in something like a
> mapper/DAO, and make it work whether or not a TransactionInterceptor
> is involved, you can use TransactionTemplate (in a somewhat convoluted
> fashion). So get a TransactionTemplate in a normal fashion, and then
> do something like this:
>
> TransactionTemplate transactionTemplate;
> ...
>
> // now set RollbackOnly via TransactionTemplate; we should join the
> current transaction, and set rollback on that
> transactionTemplate..execute(new TransactionCallback() {
> public Object doInTransaction(TransactionStatus status) {
> status.setRollbackOnly();
> return null;
> }
> });
>
> Regards,
> Colin
>
>
> Rod Johnson wrote:
>
>> 1. you don't need to use an unchecked exception, you can set a
>> declarative
>> rollback rule for the relevant checked exception
>>
>> 2. If you do want programmatic rollback you do it like this
>>
>> TransactionInterceptor.currentTransactionStatus().setRollbackOnly().
>>
>> As in .NET it's static--no need to pass around something like an
>> EJBContext.
>> currentTransactionStatus() will throw NoTransactionException if you
>> don't
>> have a tx context. Put the static call in a protected method or =
strategy
>> class so you can override it at test time.
>>
>> ----- Original Message -----
>> From: "Sean Radford" <sra...@bl...>
>> To: <spr...@li...>
>> Sent: Friday, February 06, 2004 8:04 PM
>> Subject: [Springframework-user] Retrieving the current transaction
>>
>>
>> Hi all,
>>
>>
>> If one is 'in' a Business Object or DAO class (as defined below), how
>> does one get the current Transaction in order to set it to rollback? =
(I
>> don't want to (can't) throw a RuntimeException to get it to happen =
that
>> way).
>>
>>
>> <bean id=3D"fooDAO" class=3D"my.FooDAOImpl">
>> <property name=3D"sessionFactory">
>> <ref bean=3D"hibernateSessionFactory"/>
>> </property>
>> </bean>
>>
>> <bean id=3D"fooBoTarget" class=3Dmy.FooBO" singleton=3D"true">
>> <property name=3D"fooDAO">
>> <ref bean=3D"fooDAO"/>
>> </property>
>> </bean>
>>
>> <bean id=3D"eventManager"
>> =
class=3D"org.springframework.transaction.interceptor.TransactionProxyFact=
oryBe
>>
>> an">
>> <property name=3D"transactionManager">
>> <ref bean=3D"tm"/>
>> </property>
>> <property name=3D"target">
>> <ref bean=3D"fooBoTarget"/>
>> </property>
>> <property name=3D"transactionAttributes">
>> <props>
>> <prop key=3D"*">PROPAGATION_REQUIRED</prop>
>> </props>
>> </property>
>> </bean>
>>
>>
>> Regards,
>>
>> Sean
>>
>> On Fri, 2004-02-06 at 17:21, j=FCrgen h=F6ller [werk3AT] wrote:
>>=20
>>
>>> I'm pleased to announce that Spring 1.0 RC1 will ship with pre-built
>>> JOTM
>>> =20
>>
>> integration in the form of
>> org.springframework.transaction.jta.JotmFactoryBean :-)
>>=20
>>
>>> I've just been reworking the new JTA support for the upcoming =
release,
>>> =20
>>
>> turning JtaDialect into FactoryBeans that expose
>> javax.transaction.TransactionManager. JotmFactoryBean does exactly
>> that too
>> now; the exposed object implements both UserTransaction and
>> TransactionManager. In case of an existing JOTM instance, the
>> existing one
>> will be returned; else, a new local JOTM instance will be created.
>>=20
>>
>>> This can be combined with either JOnAS JNDI DataSources or locally
>>> defined
>>> =20
>>
>> XAPool DataSources, for example in the local case:
>>=20
>>
>>> <bean id=3D"jotm"
>>> =20
>>
>> class=3D"org.springframework.transaction.jta.JotmFactoryBean"/>
>>=20
>>
>>> <bean id=3D"transactionManager"
>>> =20
>>
>> class=3D"org.springframework.transaction.jta.JtaTransactionManager">
>>=20
>>
>>> <property name=3D"userTransaction"><ref =
local=3D"jotm"/></property>
>>> <property name=3D"transactionManager"><ref =
local=3D"jotm"/></property>
>>> </bean>
>>>
>>> <bean id=3D"innerDataSource"
>>> =20
>>
>> class=3D"org.enhydra.jdbc.standard.StandardXADataSource">
>>=20
>>
>>> <property name=3D"driverName">...</property>
>>> <property name=3D"url">...</property>
>>> </bean>
>>>
>>> <bean id=3D"dataSource"
>>> =20
>>
>> class=3D"org.enhydra.jdbc.pool.StandardXAPoolDataSource">
>>=20
>>
>>> <property name=3D"dataSource"><ref
>>> local=3D"innerDataSource"/></property>
>>> </bean>
>>>
>>> Thus, your code can work with "transactionManager" and "dataSource" =
as
>>> =20
>>
>> usual, just like in the JtaTransactionManager-on-J2EE case - but in a
>> standalone environment, doing XA transactions via JOTM!
>>=20
>>
>>> Juergen
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...]On Behalf =
Of
>>> j=FCrgen h=F6ller [werk3AT]
>>> Sent: Friday, February 06, 2004 2:27 PM
>>> To: spr...@li...
>>> Subject: RE: [Springframework-user] XA Transaction Support
>>>
>>>
>>> Hi Nick,
>>>
>>> ObjectWeb's XAPool comes with pre-built DataSource wrappers that are
>>> =20
>>
>> XA-capable via JOTM. Have a look at the example at
>> http://xapool.experlog.com/examples.html#xapooldatasource.
>>=20
>>
>>> You shouldn't need to do any enlisting/delisting yourself with
>>> XAPool: You
>>> =20
>>
>> just need to set up a local JOTM instance and a local XAPool
>> XADataSource,
>> configured for JOTM.
>>=20
>>
>>> For integration into Spring, a configurer for JOTM could initialize =
the
>>> =20
>>
>> transaction manager on context startup, binding the UserTransaction =
and
>> TransactionManager instances to JNDI. Of course, you need a JNDI
>> environment; maybe Spring's SimpleNamingContextBuilder is an option.
>>=20
>>
>>> Furthermore, you need a factory for javax.sql.DataSource instances: =
You
>>> =20
>>
>> might need to implement a custom factory here, setting up an XAPool
>> XADataSource, connecting it to the JNDI-bound TransactionManager, and
>> wrapping it in a plain DataSource (to be passed to JDBC access code
>> etc).
>>=20
>>
>>> Spring's JtaTransactionManager should work nicely with such a JOTM
>>> setup,
>>> =20
>>
>> simply accessing the UserTransaction under the given JNDI name. Note
>> that as
>> of 1.0 RC1, we even support transaction suspension now, and thus all
>> six EJB
>> CMT propagation codes (including REQUIRES_NEW etc). You just need to
>> set up
>> a Spring JtaDialect for this.
>>=20
>>
>>> To avoid the need for a JNDI environment (you just need it for the =
JTA
>>> =20
>>
>> UserTransaction and TransactionManager), you could also implement
>> FactoryBeans that expose the UserTransaction respectively the
>> TransactionManager from the JOTM configuration, to be passed as bean
>> references to JtaTransactionManager and XADataSource FactoryBeans.
>>=20
>>
>>> Of course, I'd be happy to accept code donations to Spring regarding
>>> JOTM
>>> =20
>>
>> integration :-) Feel free to ask for help if you encounter any =
issues.
>>=20
>>
>>> Juergen
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> =20
>>
>> [mailto:spr...@li...]On Behalf Of
>> Nick
>> Minutello
>>=20
>>
>>> Sent: Friday, February 06, 2004 11:39 AM
>>> To: spr...@li...
>>> Subject: [Springframework-user] XA Transaction Support
>>>
>>>
>>> Hi,
>>> I have to do some out-of-appserver XA transaction management.
>>> (planning on
>>> =20
>>
>> using JOTM)
>>=20
>>
>>> I was thinking of using an interceptor around the
>>> XAConnectionFactory and
>>> =20
>>
>> the XADataSource getConnection/close methods to do the enlist/delist
>> actions.
>>=20
>>
>>> I guess the question is: Is there a better way to do it with
>>> Spring's tx
>>> =20
>>
>> support?
>>=20
>>
>>> Cheers,
>>> Nick
>>>
>>>
>>> -------------------------------------------------------
>>> The SF.Net email is sponsored by EclipseCon 2004
>>> Premiere Conference on Open Tools Development and Integration
>>> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>>> http://www.eclipsecon.org/osdn
>>> _______________________________________________
>>> Springframework-user mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-user
>>>
>>>
>>> -------------------------------------------------------
>>> The SF.Net email is sponsored by EclipseCon 2004
>>> Premiere Conference on Open Tools Development and Integration
>>> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>>> http://www.eclipsecon.org/osdn
>>> _______________________________________________
>>> Springframework-user mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-user
>>> =20
>>
>> --
>> Dr. Sean Radford, MBBS, MSc
>> sra...@bl...
>> http://bladesys.demon.co.uk/
>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|