osdir.com
mailing list archive

Subject: Re: Is Spring transaction management worthusing? - msg#00527

List: java.springframework.user

Date: Prev Next Index Thread: Prev Next Index
Brandon,

I think it's pretty clear from our docs and samples that Spring's
JtaTransactionManager itself works just nicely in a container-independent
fashion - in typical usage scenarios where you could use a plain JTA
javax.transaction.UserTransaction too.
We have always clarified this when a corresponding question has popped up on
the forums.

As Dmitriy has outlined, you just need container-specific configuration for
more advanced usage, namely transaction suspension and Hibernate cache
completion callbacks. The simple reason for this is that you need the JTA
javax.transaction.TransactionManager to suspend/resume transactions and
register transaction synchronizations; the UserTransaction interface does not
support that functionality.

Unfortunately, J2EE does not specify how to access the JTA TransactionManager,
just the common JNDI location of the JTA UserTransaction - so the lookup of the
JTA TransactionManager has to be container-specific. This is the case with
Hibernate (see TransactionManagerLookup), this is the case with Spring, this is
the case with any such tool.

So for typical usages, simple declare Spring's JtaTransactionManager without
any properties. Just for transaction suspension, specify a
"transactionManagerName" (JNDI location of the JTA TransactionManager) or a
"transactionManager" reference (from JndiObjectFactoryBean, to centrally define
the JNDI location; or from a special lookup strategy, like JotmFactoryBean or
WebSphereTransactionManagerFactoryBean).

-----

For Hibernate cache completion callbacks with JTA, you need to specify a
corresponding TransactionManagerLookup in the Hibernate properties. As an
alternative, Spring allows you to pass a JTA TransactionManager into
LocalSessionFactoryBean's "jtaTransactionManager" property, to reuse a
centrally defined TransactionManager reference that can be shared with
JtaTransactionManager's "transactionManager" property.

Note that you'll also get proper Hibernate cache completion callbacks without
such a container-specific TransactionManagerLookup, as long as you use Spring's
transaction management - because Spring has its own transaction synchronization
mechanism. So even for proper Hibernate callbacks with Spring, there is
typically no need for container-specific JTA configuration; a plain
JtaTransactionManager definition is fine.

That said, there is an issue with WebLogic/WebSphere and Hibernate, which is
also what keeps popping up on our forums: Those containers have very rigid JTA
implementations that don't allow any access to a transactional JDBC Connection
after transaction completion. Because of this, Spring's standard Hibernate
cache completion callback causes a warning in the logs; an additional
container-specific Hibernate TransactionManagerLookup avoids this.

-----

All things considered, to the best of my knowledge, Spring's JTA support is as
strong as can be. It even includes special support for Hibernate/JTA
integration, which addresses typical Hibernate issues. Spring cannot offer more
than it does already, as JTA simply doesn't specify more functionality. It
cannot simplify JTA configuration either, as the remaining limits are caused by
JTA itself.

In particular, Spring's transaction management offers all 6 propagation
behavior types that EJB CMT defines (REQUIRED, REQUIRES_NEW, etc). In the case
of JTA, REQUIRES_NEW and NOT_SUPPORTED can just be offered if the
javax.transaction.TransactionManager is accessible, which requires a
container-specific lookup - a J2EE/JTA issue that is not caused by Spring, and
faced by all tools that work with JTA in a J2EE environment.

Side note: Spring's other transaction strategies, namely
DataSourceTransactionManager, HibernateTransactionManager and
JdoTransactionManager, offer all 6 propagation behavior types too - without any
container-specific configuration. Furthermore, the former two also offer
per-transaction isolation levels, which is a concept not supported by JTA in
the first place. Some transaction strategies support "read-only transactions"
too, for example HibernateTransactionManager.

-----

Please, before you quote anonymous sources that say that "JTA support is poor"
and speculate about problems "when containers upgrade" - without specific
problems, and on a public user forum of the product that you're questioning -,
spend a few minutes checking your facts. A look into the docs/javadocs - or a
detailed read of answers to those forum questions you referred to - would have
revealed that those assumptions are obviously wrong.

So, now that we've removed that obstacle: If you've got any further questions
regarding Spring's transaction support (*after* a look at the docs), feel free
to ask me: be it about usage patterns, implementation internals, issues with
specific persistence tools, or issues with specific J2EE containers. I'll also
be happy to clarify any issues regarding Spring's support for iBATIS SQL Maps,
which is obviously of interest to you :-)

Juergen


________________________________

Von: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx im Auftrag von Dmitriy
Kopylenko
Gesendet: Sa 29.05.2004 05:44
An: springframework-user@xxxxxxxxxxxxxxxxxxxxx
Betreff: Re: [Springframework-user] Is Spring transaction management worthusing?


Brandon, thanks for your reply.

Let me briefly say that Spring provides completely generic implementation of
PlatformTransactionManager namely JtaTransactionManager which handles most of
the use cases for generic J2EE global transactions such as distributed
transactions and managing transactions on J2EE connector (JCA resource adapter).

In order to support transaction suspension (REQUIRES_NEW, NOT_SUPPORTED),
Spring needs to get hold of JTA TransactionManager which is an internal JTA
object and its location is not specified by J2EE spec. and is individual for
each J2EE container.

Spring provides two FactoryBean implementations for JOTM and WebSphere to
obtain the JtaTransactionManager for respective JTA implementations, as static
accessor methods are required to get hold of TransactionManager for both JOTM
and WebSphere...

I'm not sure about a potential problem with containers upgrade. I'll let
Juergen, Rod and others comment on this.

Regards,
Dmitriy.


Brandon Goodin wrote:


I'm just trying to find out if there are any serious problems with
Transaction Management. Looking into the archives it seems the chief complaint
is that spring has to provide specific container support for JTA Transaction
Management. That could pose a problem as containers upgrade. Projects using
spring would need to make sure that Spring has support for their container
before proceeding with a point upgrade. This is in line with what I heard from
another source. Is this an accurate portrayal?



Brandon Goodin




________________________________


From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx
[mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dmitriy
Kopylenko
Sent: Friday, May 28, 2004 8:04 PM
To: springframework-user@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Springframework-user] Is Spring transaction management
worthusing?



Brandon, I'm sorry, but from your email it's not clear what you mean.
You said: "in general I've heard that the JTA support is poor" I just what to
find out from whom you heard that statement? In general I could tell you one
thing - Spring's JTA support is not poor at all ;-)

Regards,
Dmitriy.

Brandon Goodin wrote:



Why are you asking me a question that I have already answered? Read my
email and you may find the answer to your question. ;-)



Brandon




________________________________


From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx
[mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dmitriy
Kopylenko
Sent: Friday, May 28, 2004 7:34 PM
To: springframework-user@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Springframework-user] Is Spring transaction management
worthusing?



I'm just curious - where did you hear that "the JTA support is poor"
and what are the specific areas of this "poor support"?

Dmitriy.

Brandon Goodin wrote:




Specifically, I have nothing. But, in general I've heard that the JTA
support is poor. I'm just curious if anyone can give me a clear blow for
blow on where the Transaction capabilities are strong and where they
need
some work.

Brandon Goodin



-----Original Message-----
From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx
[mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On
Behalf Of
Nadeem Bitar
Sent: Friday, May 28, 2004 5:30 PM
To: springframework-user@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Springframework-user] Is Spring transaction
management
worthusing?

On ?, 2004-05-28 at 18:11 -0700, Brandon Goodin wrote:


I've heard that there are issues with the Spring
transaction
management. Can someone explain to me the pros and cons
of Spring's
management of transactions?



Which issues? because I having been using it for a year without
any
problem.




Brandon Goodin






-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market...
Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=click
_______________________________________________
Springframework-user mailing list
Springframework-user@xxxxxxxxxxxxxxxxxxxxx

https://lists.sourceforge.net/lists/listinfo/springframework-user






-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle
10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Springframework-user mailing list
Springframework-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/springframework-user









-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id?66&op=click


Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

Re: looking up local or remote objects w/o changing client code

Keith Donald wrote: Bruce, You should never have to change the client code when you switch between a proxy to an EJB-fronted façade of a POJO service or the POJO service itself. In either case, you always want to inject the business interface of the said service to your clients, irrelevant of whether that interface is backed by EJB. That's one of the main benefits of IoC. If you'd prefer to use "dependency lookup" as opposed to "dependency injection", you can grab the service interface out of the context using applicationContext.getBean(serviceName). In that case you're still independent of whether that service is local, remote, or is or is not backed by EJB; you should just get back an object castable to the service's business interface. I still prefer "dependency injection"-style IoC to lookup, as with a context lookup your client code is now dependent on a Spring application context. Alternatively, you could inject your own service locator interface that wraps a context lookup if you prefer a lookup strategy but not a dependency on Spring. Here are some examples: Proxy to a local EJB (see the SimpleRemote flavor for a remote EJB): <bean id=“ejbServiceProxy" class=“org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean" <property name="jndiName"> <value>myEjb</value> </property> <property name="businessInterface"> <value>com.mycompany.domain.MyBusinessInterface</value> </property> </bean> Plain old POJO direct reference: <bean id="service" class="com.mycompany.domain.MyBusinessServiceImpl"> <property> ... </property> </bean> Client of services: <bean id="myClient" class="com.mycompany.client.MyClient"> <property name="myService"><ref bean="service"></property> </bean> To use the EJB proxy, simply replace the client reference to the "service" bean with the reference to "ejbServiceProxy" -- a matter of configuration; since both implement the same business interface, the client doesn't know the difference. You may want different context files for the different sets of configurations, particularly if your client's lookup each service by a common, well-known name. Keith -----Original Message----- From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Bruce Snyder Sent: Thursday, May 27, 2004 8:01 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: [Springframework-user] looking up local or remote objects w/o changing client code I am developing all business logic in POJOs and wrapping them in SLSBs when they need to run in a J2EE container. But there are also times where that POJO needs to be instantiated in the J2SE world. I don't want to change the client code depending on whether a service will be local or remote. I want my client code to be able to call: ServiceFactory.getBean( "nameOfBean" ); and get back the real impl if it's local or a dynamic remote proxy if it's remote. I've got the dynamic remote proxies working great with Spring, but only if the client code calls: BlahService service = BlahServiceUtil.getHome().create(); How can I get Spring to distinguish a local lookup from a remote lookup and allow my client code to remain the same? Colin, Oliver, Keith, Thank you all for responding to me. The same theme is appearing throughout each response - the notion of the client code shouldn't change no matter what the impl behind the scenes. This is one of the big reasons I chose to use Spring so I'm very aware of this. What I failed to understand was how to achieve this when a service could be either a remote EJB or a local POJO. Last night I figured it out and fixed my mistakes. Thank you very much for the feedback and the examples. Bruce -- perl -e 'print unpack("u30","<0G)U8V4\\@4VYY9&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");' The Castor Project http://www.castor.org/ Apache Geronimo http://incubator.apache.org/projects/geronimo.html ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id?66&op=click

Next Message by Date: click to view message preview

RE: Is Spring transaction management worthusing?

Well, i meant no malice. I HAVE read the documentation. I HAVE used the transaction management and liked it quite well. However, i am new to spring and I was simply looking to find out what the REAL story was on what i was being told. So, what better place to go to than the knowledgeable? Also, the prior posts that i read were specific problems with implementations and i certainly read that they were resolved. I was just looking to see if there were any other issues related to those TYPE of problems that would cause someone to take issue with your transaction management. If you noticed... my final question was "Is this an accurate portrayal?". Also, why do you have a problem with people asking these types of questions on a "public forum". That's silliness imo. We field questions like this on the ibatis list without problem. Besides, if the rumor is in fact floating around, what better place is there to resolve it? I appreciate all the responses and i think it clears up my question quite well. Thank You. Brandon Goodin -----Original Message----- From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx]On Behalf Of jürgen höller [werk3AT] Sent: Saturday, May 29, 2004 11:23 AM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? Brandon, I think it's pretty clear from our docs and samples that Spring's JtaTransactionManager itself works just nicely in a container-independent fashion - in typical usage scenarios where you could use a plain JTA javax.transaction.UserTransaction too. We have always clarified this when a corresponding question has popped up on the forums. As Dmitriy has outlined, you just need container-specific configuration for more advanced usage, namely transaction suspension and Hibernate cache completion callbacks. The simple reason for this is that you need the JTA javax.transaction.TransactionManager to suspend/resume transactions and register transaction synchronizations; the UserTransaction interface does not support that functionality. Unfortunately, J2EE does not specify how to access the JTA TransactionManager, just the common JNDI location of the JTA UserTransaction - so the lookup of the JTA TransactionManager has to be container-specific. This is the case with Hibernate (see TransactionManagerLookup), this is the case with Spring, this is the case with any such tool. So for typical usages, simple declare Spring's JtaTransactionManager without any properties. Just for transaction suspension, specify a "transactionManagerName" (JNDI location of the JTA TransactionManager) or a "transactionManager" reference (from JndiObjectFactoryBean, to centrally define the JNDI location; or from a special lookup strategy, like JotmFactoryBean or WebSphereTransactionManagerFactoryBean). ----- For Hibernate cache completion callbacks with JTA, you need to specify a corresponding TransactionManagerLookup in the Hibernate properties. As an alternative, Spring allows you to pass a JTA TransactionManager into LocalSessionFactoryBean's "jtaTransactionManager" property, to reuse a centrally defined TransactionManager reference that can be shared with JtaTransactionManager's "transactionManager" property. Note that you'll also get proper Hibernate cache completion callbacks without such a container-specific TransactionManagerLookup, as long as you use Spring's transaction management - because Spring has its own transaction synchronization mechanism. So even for proper Hibernate callbacks with Spring, there is typically no need for container-specific JTA configuration; a plain JtaTransactionManager definition is fine. That said, there is an issue with WebLogic/WebSphere and Hibernate, which is also what keeps popping up on our forums: Those containers have very rigid JTA implementations that don't allow any access to a transactional JDBC Connection after transaction completion. Because of this, Spring's standard Hibernate cache completion callback causes a warning in the logs; an additional container-specific Hibernate TransactionManagerLookup avoids this. ----- All things considered, to the best of my knowledge, Spring's JTA support is as strong as can be. It even includes special support for Hibernate/JTA integration, which addresses typical Hibernate issues. Spring cannot offer more than it does already, as JTA simply doesn't specify more functionality. It cannot simplify JTA configuration either, as the remaining limits are caused by JTA itself. In particular, Spring's transaction management offers all 6 propagation behavior types that EJB CMT defines (REQUIRED, REQUIRES_NEW, etc). In the case of JTA, REQUIRES_NEW and NOT_SUPPORTED can just be offered if the javax.transaction.TransactionManager is accessible, which requires a container-specific lookup - a J2EE/JTA issue that is not caused by Spring, and faced by all tools that work with JTA in a J2EE environment. Side note: Spring's other transaction strategies, namely DataSourceTransactionManager, HibernateTransactionManager and JdoTransactionManager, offer all 6 propagation behavior types too - without any container-specific configuration. Furthermore, the former two also offer per-transaction isolation levels, which is a concept not supported by JTA in the first place. Some transaction strategies support "read-only transactions" too, for example HibernateTransactionManager. ----- Please, before you quote anonymous sources that say that "JTA support is poor" and speculate about problems "when containers upgrade" - without specific problems, and on a public user forum of the product that you're questioning -, spend a few minutes checking your facts. A look into the docs/javadocs - or a detailed read of answers to those forum questions you referred to - would have revealed that those assumptions are obviously wrong. So, now that we've removed that obstacle: If you've got any further questions regarding Spring's transaction support (*after* a look at the docs), feel free to ask me: be it about usage patterns, implementation internals, issues with specific persistence tools, or issues with specific J2EE containers. I'll also be happy to clarify any issues regarding Spring's support for iBATIS SQL Maps, which is obviously of interest to you :-) Juergen ________________________________ Von: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx im Auftrag von Dmitriy Kopylenko Gesendet: Sa 29.05.2004 05:44 An: springframework-user@xxxxxxxxxxxxxxxxxxxxx Betreff: Re: [Springframework-user] Is Spring transaction management worthusing? Brandon, thanks for your reply. Let me briefly say that Spring provides completely generic implementation of PlatformTransactionManager namely JtaTransactionManager which handles most of the use cases for generic J2EE global transactions such as distributed transactions and managing transactions on J2EE connector (JCA resource adapter). In order to support transaction suspension (REQUIRES_NEW, NOT_SUPPORTED), Spring needs to get hold of JTA TransactionManager which is an internal JTA object and its location is not specified by J2EE spec. and is individual for each J2EE container. Spring provides two FactoryBean implementations for JOTM and WebSphere to obtain the JtaTransactionManager for respective JTA implementations, as static accessor methods are required to get hold of TransactionManager for both JOTM and WebSphere... I'm not sure about a potential problem with containers upgrade. I'll let Juergen, Rod and others comment on this. Regards, Dmitriy. Brandon Goodin wrote: I'm just trying to find out if there are any serious problems with Transaction Management. Looking into the archives it seems the chief complaint is that spring has to provide specific container support for JTA Transaction Management. That could pose a problem as containers upgrade. Projects using spring would need to make sure that Spring has support for their container before proceeding with a point upgrade. This is in line with what I heard from another source. Is this an accurate portrayal? Brandon Goodin ________________________________ From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dmitriy Kopylenko Sent: Friday, May 28, 2004 8:04 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? Brandon, I'm sorry, but from your email it's not clear what you mean. You said: "in general I've heard that the JTA support is poor" I just what to find out from whom you heard that statement? In general I could tell you one thing - Spring's JTA support is not poor at all ;-) Regards, Dmitriy. Brandon Goodin wrote: Why are you asking me a question that I have already answered? Read my email and you may find the answer to your question. ;-) Brandon ________________________________ From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dmitriy Kopylenko Sent: Friday, May 28, 2004 7:34 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? I'm just curious - where did you hear that "the JTA support is poor" and what are the specific areas of this "poor support"? Dmitriy. Brandon Goodin wrote: Specifically, I have nothing. But, in general I've heard that the JTA support is poor. I'm just curious if anyone can give me a clear blow for blow on where the Transaction capabilities are strong and where they need some work. Brandon Goodin -----Original Message----- From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Nadeem Bitar Sent: Friday, May 28, 2004 5:30 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? On ?, 2004-05-28 at 18:11 -0700, Brandon Goodin wrote: I've heard that there are issues with the Spring transaction management. Can someone explain to me the pros and cons of Spring's management of transactions? Which issues? because I having been using it for a year without any problem. Brandon Goodin ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id66&op=click _______________________________________________ Springframework-user mailing list Springframework-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Springframework-user mailing list Springframework-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id?66&op=click _______________________________________________ Springframework-user mailing list Springframework-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id?66&op=click

Previous Message by Thread: click to view message preview

Is Spring transaction management worth using?

I’ve heard that there are issues with the Spring transaction management. Can someone explain to me the pros and cons of Spring’s management of transactions?   Brandon Goodin

Next Message by Thread: click to view message preview

RE: Is Spring transaction management worthusing?

Well, i meant no malice. I HAVE read the documentation. I HAVE used the transaction management and liked it quite well. However, i am new to spring and I was simply looking to find out what the REAL story was on what i was being told. So, what better place to go to than the knowledgeable? Also, the prior posts that i read were specific problems with implementations and i certainly read that they were resolved. I was just looking to see if there were any other issues related to those TYPE of problems that would cause someone to take issue with your transaction management. If you noticed... my final question was "Is this an accurate portrayal?". Also, why do you have a problem with people asking these types of questions on a "public forum". That's silliness imo. We field questions like this on the ibatis list without problem. Besides, if the rumor is in fact floating around, what better place is there to resolve it? I appreciate all the responses and i think it clears up my question quite well. Thank You. Brandon Goodin -----Original Message----- From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx]On Behalf Of jürgen höller [werk3AT] Sent: Saturday, May 29, 2004 11:23 AM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? Brandon, I think it's pretty clear from our docs and samples that Spring's JtaTransactionManager itself works just nicely in a container-independent fashion - in typical usage scenarios where you could use a plain JTA javax.transaction.UserTransaction too. We have always clarified this when a corresponding question has popped up on the forums. As Dmitriy has outlined, you just need container-specific configuration for more advanced usage, namely transaction suspension and Hibernate cache completion callbacks. The simple reason for this is that you need the JTA javax.transaction.TransactionManager to suspend/resume transactions and register transaction synchronizations; the UserTransaction interface does not support that functionality. Unfortunately, J2EE does not specify how to access the JTA TransactionManager, just the common JNDI location of the JTA UserTransaction - so the lookup of the JTA TransactionManager has to be container-specific. This is the case with Hibernate (see TransactionManagerLookup), this is the case with Spring, this is the case with any such tool. So for typical usages, simple declare Spring's JtaTransactionManager without any properties. Just for transaction suspension, specify a "transactionManagerName" (JNDI location of the JTA TransactionManager) or a "transactionManager" reference (from JndiObjectFactoryBean, to centrally define the JNDI location; or from a special lookup strategy, like JotmFactoryBean or WebSphereTransactionManagerFactoryBean). ----- For Hibernate cache completion callbacks with JTA, you need to specify a corresponding TransactionManagerLookup in the Hibernate properties. As an alternative, Spring allows you to pass a JTA TransactionManager into LocalSessionFactoryBean's "jtaTransactionManager" property, to reuse a centrally defined TransactionManager reference that can be shared with JtaTransactionManager's "transactionManager" property. Note that you'll also get proper Hibernate cache completion callbacks without such a container-specific TransactionManagerLookup, as long as you use Spring's transaction management - because Spring has its own transaction synchronization mechanism. So even for proper Hibernate callbacks with Spring, there is typically no need for container-specific JTA configuration; a plain JtaTransactionManager definition is fine. That said, there is an issue with WebLogic/WebSphere and Hibernate, which is also what keeps popping up on our forums: Those containers have very rigid JTA implementations that don't allow any access to a transactional JDBC Connection after transaction completion. Because of this, Spring's standard Hibernate cache completion callback causes a warning in the logs; an additional container-specific Hibernate TransactionManagerLookup avoids this. ----- All things considered, to the best of my knowledge, Spring's JTA support is as strong as can be. It even includes special support for Hibernate/JTA integration, which addresses typical Hibernate issues. Spring cannot offer more than it does already, as JTA simply doesn't specify more functionality. It cannot simplify JTA configuration either, as the remaining limits are caused by JTA itself. In particular, Spring's transaction management offers all 6 propagation behavior types that EJB CMT defines (REQUIRED, REQUIRES_NEW, etc). In the case of JTA, REQUIRES_NEW and NOT_SUPPORTED can just be offered if the javax.transaction.TransactionManager is accessible, which requires a container-specific lookup - a J2EE/JTA issue that is not caused by Spring, and faced by all tools that work with JTA in a J2EE environment. Side note: Spring's other transaction strategies, namely DataSourceTransactionManager, HibernateTransactionManager and JdoTransactionManager, offer all 6 propagation behavior types too - without any container-specific configuration. Furthermore, the former two also offer per-transaction isolation levels, which is a concept not supported by JTA in the first place. Some transaction strategies support "read-only transactions" too, for example HibernateTransactionManager. ----- Please, before you quote anonymous sources that say that "JTA support is poor" and speculate about problems "when containers upgrade" - without specific problems, and on a public user forum of the product that you're questioning -, spend a few minutes checking your facts. A look into the docs/javadocs - or a detailed read of answers to those forum questions you referred to - would have revealed that those assumptions are obviously wrong. So, now that we've removed that obstacle: If you've got any further questions regarding Spring's transaction support (*after* a look at the docs), feel free to ask me: be it about usage patterns, implementation internals, issues with specific persistence tools, or issues with specific J2EE containers. I'll also be happy to clarify any issues regarding Spring's support for iBATIS SQL Maps, which is obviously of interest to you :-) Juergen ________________________________ Von: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx im Auftrag von Dmitriy Kopylenko Gesendet: Sa 29.05.2004 05:44 An: springframework-user@xxxxxxxxxxxxxxxxxxxxx Betreff: Re: [Springframework-user] Is Spring transaction management worthusing? Brandon, thanks for your reply. Let me briefly say that Spring provides completely generic implementation of PlatformTransactionManager namely JtaTransactionManager which handles most of the use cases for generic J2EE global transactions such as distributed transactions and managing transactions on J2EE connector (JCA resource adapter). In order to support transaction suspension (REQUIRES_NEW, NOT_SUPPORTED), Spring needs to get hold of JTA TransactionManager which is an internal JTA object and its location is not specified by J2EE spec. and is individual for each J2EE container. Spring provides two FactoryBean implementations for JOTM and WebSphere to obtain the JtaTransactionManager for respective JTA implementations, as static accessor methods are required to get hold of TransactionManager for both JOTM and WebSphere... I'm not sure about a potential problem with containers upgrade. I'll let Juergen, Rod and others comment on this. Regards, Dmitriy. Brandon Goodin wrote: I'm just trying to find out if there are any serious problems with Transaction Management. Looking into the archives it seems the chief complaint is that spring has to provide specific container support for JTA Transaction Management. That could pose a problem as containers upgrade. Projects using spring would need to make sure that Spring has support for their container before proceeding with a point upgrade. This is in line with what I heard from another source. Is this an accurate portrayal? Brandon Goodin ________________________________ From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dmitriy Kopylenko Sent: Friday, May 28, 2004 8:04 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? Brandon, I'm sorry, but from your email it's not clear what you mean. You said: "in general I've heard that the JTA support is poor" I just what to find out from whom you heard that statement? In general I could tell you one thing - Spring's JTA support is not poor at all ;-) Regards, Dmitriy. Brandon Goodin wrote: Why are you asking me a question that I have already answered? Read my email and you may find the answer to your question. ;-) Brandon ________________________________ From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dmitriy Kopylenko Sent: Friday, May 28, 2004 7:34 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? I'm just curious - where did you hear that "the JTA support is poor" and what are the specific areas of this "poor support"? Dmitriy. Brandon Goodin wrote: Specifically, I have nothing. But, in general I've heard that the JTA support is poor. I'm just curious if anyone can give me a clear blow for blow on where the Transaction capabilities are strong and where they need some work. Brandon Goodin -----Original Message----- From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Nadeem Bitar Sent: Friday, May 28, 2004 5:30 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? On ?, 2004-05-28 at 18:11 -0700, Brandon Goodin wrote: I've heard that there are issues with the Spring transaction management. Can someone explain to me the pros and cons of Spring's management of transactions? Which issues? because I having been using it for a year without any problem. Brandon Goodin ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id66&op=click _______________________________________________ Springframework-user mailing list Springframework-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Springframework-user mailing list Springframework-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id?66&op=click _______________________________________________ Springframework-user mailing list Springframework-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id?66&op=click
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by