|
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
|
|
From: Colin S. <col...@ex...> - 2004-02-07 21:40:34
|
Guys, is it worth adding a convenience method for setRollbackOnly, to=20
TransactionTemplate, something like this? It's a lot more intuitive than=20
the anonymous class method below.
public void setRollbackOnly() throws TransactionException {
TransactionStatus status =3D this.transactionManager.getTransaction(t=
his);
if (status.isNew)
throw new TransactionUsageException("unable to join existing=20
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=20
> involved. Alternately, if you want to do this in something like a=20
> mapper/DAO, and make it work whether or not a TransactionInterceptor=20
> is involved, you can use TransactionTemplate (in a somewhat convoluted=20
> fashion). So get a TransactionTemplate in a normal fashion, and then=20
> do something like this:
>
> TransactionTemplate transactionTemplate;
> ...
>
> // now set RollbackOnly via TransactionTemplate; we should join the=20
> 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=20
>> 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=20
>> EJBContext.
>> currentTransactionStatus() will throw NoTransactionException if you=20
>> don't
>> have a tx context. Put the static call in a protected method or strate=
gy
>> 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 tha=
t
>> 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.TransactionProxyF=
actoryBe=20
>>
>> 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=20
>>> 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=20
>> that too
>> now; the exposed object implements both UserTransaction and
>> TransactionManager. In case of an existing JOTM instance, the=20
>> 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=20
>>> 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"/></prope=
rty>
>>> </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=20
>>> local=3D"innerDataSource"/></property>
>>> </bean>
>>>
>>> Thus, your code can work with "transactionManager" and "dataSource" a=
s
>>> =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=20
>>> XAPool: You
>>> =20
>>
>> just need to set up a local JOTM instance and a local XAPool=20
>> XADataSource,
>> configured for JOTM.
>> =20
>>
>>> For integration into Spring, a configurer for JOTM could initialize t=
he
>>> =20
>>
>> transaction manager on context startup, binding the UserTransaction an=
d
>> 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: Y=
ou
>>> =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=20
>> etc).
>> =20
>>
>>> Spring's JtaTransactionManager should work nicely with such a JOTM=20
>>> setup,
>>> =20
>>
>> simply accessing the UserTransaction under the given JNDI name. Note=20
>> that as
>> of 1.0 RC1, we even support transaction suspension now, and thus all=20
>> six EJB
>> CMT propagation codes (including REQUIRES_NEW etc). You just need to=20
>> set up
>> a Spring JtaDialect for this.
>> =20
>>
>>> To avoid the need for a JNDI environment (you just need it for the JT=
A
>>> =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=20
>>> 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=20
>> 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.=20
>>> (planning on
>>> =20
>>
>> using JOTM)
>> =20
>>
>>> I was thinking of using an interceptor around the=20
>>> 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=20
>>> 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
>>
>> --=20
>> Dr. Sean Radford, MBBS, MSc
>> sra...@bl...
>> http://bladesys.demon.co.uk/
>
|
|
From: Colin S. <col...@ex...> - 2004-02-06 23:15:55
|
In fact, unless I am confused, the use of
TransactionInterceptor.currentTransactionStatus().setRollbackOnly()
is problematic. It can not handle the mixed use of a=20
TransactionInterceptor and a contained TransactionTemplate which=20
initiates its own (nested) transaction (due to REQUIRES_NEW being set on=20
its propogation setting).
The user calling
TransactionInterceptor.currentTransactionStatus().setRollbackOnly()
would be setting rollbackonly on the outer transaction status, which was=20
created by the TransactionInterceptor, while in fact he wants to be=20
calling it on the status of the inner transaction he is in...
Colin Sampaleanu wrote:
> Guys, is it worth adding a convenience method for setRollbackOnly, to=20
> TransactionTemplate, something like this? It's a lot more intuitive=20
> than the anonymous class method below.
>
> public void setRollbackOnly() throws TransactionException {
>
> TransactionStatus status =3D=20
> this.transactionManager.getTransaction(this);
> if (status.isNew)
> throw new TransactionUsageException("unable to join existing=20
> 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=20
>> involved. Alternately, if you want to do this in something like a=20
>> mapper/DAO, and make it work whether or not a TransactionInterceptor=20
>> is involved, you can use TransactionTemplate (in a somewhat=20
>> convoluted fashion). So get a TransactionTemplate in a normal=20
>> fashion, and then do something like this:
>>
>> TransactionTemplate transactionTemplate;
>> ...
>>
>> // now set RollbackOnly via TransactionTemplate; we should join=20
>> 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=20
>>> 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=20
>>> EJBContext.
>>> currentTransactionStatus() will throw NoTransactionException if you=20
>>> don't
>>> have a tx context. Put the static call in a protected method or=20
>>> 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 th=
at
>>> 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.TransactionProxy=
FactoryBe=20
>>>
>>> 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=20
>>>> 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 releas=
e,
>>>> =20
>>>
>>>
>>> turning JtaDialect into FactoryBeans that expose
>>> javax.transaction.TransactionManager. JotmFactoryBean does exactly=20
>>> that too
>>> now; the exposed object implements both UserTransaction and
>>> TransactionManager. In case of an existing JOTM instance, the=20
>>> 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=20
>>>> 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"/></propert=
y>
>>>> <property name=3D"transactionManager"><ref local=3D"jotm"/></prop=
erty>
>>>> </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=20
>>>> 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 O=
f
>>>> 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=20
>>>> XAPool: You
>>>> =20
>>>
>>>
>>> just need to set up a local JOTM instance and a local XAPool=20
>>> XADataSource,
>>> configured for JOTM.
>>> =20
>>>
>>>> For integration into Spring, a configurer for JOTM could initialize=20
>>>> the
>>>> =20
>>>
>>>
>>> transaction manager on context startup, binding the UserTransaction a=
nd
>>> 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:=20
>>>> 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=20
>>> etc).
>>> =20
>>>
>>>> Spring's JtaTransactionManager should work nicely with such a JOTM=20
>>>> setup,
>>>> =20
>>>
>>>
>>> simply accessing the UserTransaction under the given JNDI name. Note=20
>>> that as
>>> of 1.0 RC1, we even support transaction suspension now, and thus all=20
>>> six EJB
>>> CMT propagation codes (including REQUIRES_NEW etc). You just need to=20
>>> set up
>>> a Spring JtaDialect for this.
>>> =20
>>>
>>>> To avoid the need for a JNDI environment (you just need it for the J=
TA
>>>> =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=20
>>>> 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=20
>>> 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.=20
>>>> (planning on
>>>> =20
>>>
>>>
>>> using JOTM)
>>> =20
>>>
>>>> I was thinking of using an interceptor around the=20
>>>> 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=20
>>>> Spring's tx
>>>> =20
>>>
>>>
>>> support?
>>> =20
>>>
>>>> Cheers,
>>>> Nick
>>>
|
|
From: Colin S. <col...@ex...> - 2004-02-08 15:57:30
|
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
|