Re: [Springframework-developer] JTA transaction suspension on WebSphere

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

I'll add this to the wiki and/or the manual. I wonder which is more 
appropriate? As for CMT+Spring Tx, it also works in JBoss, albeit you 
can get spurious warnings about unknown connections or it closing 
connections for you (and in both cases the warnings seem to be 
spurious), under some circumsances...

Colin


jürgen höller [werk3AT] wrote:

>Current summary of Spring/JTA compatibility:
>
>
>Spring's JtaTransactionManager within EJB BMT or web components:
>
>* Everything but transaction suspension will work properly on any J2EE server, as it just touches the JTA UserTransaction, which is properly covered by standard J2EE.
>
>* Transaction suspension (REQUIRES_NEW, NOT_SUPPORTED) requires the JTA TransactionManager, which is not a public component of standard J2EE. However, it is a standard JTA interface, defined by the JTA spec, with somewhat well-defined semantics to rely on if - it is available.
>
>* Vendor-specific lookup of JTA TransactionManager is necessary, as J2EE does not define a standard location for it. By default, we autodetect whether the UserTransaction object implements the TransactionManager interface, which is the case of for a surprisingly large number of J2EE servers.
>
>* The BEA docs state that the JTA TransactionManager is officially supported for EJB BMT and web components, on both 7.0 and 8.1. It even explictly mentions that one reason to do this is transaction suspension. Official support for other vendors remains to be checked.
>
>* WebLogic needs "forceResume" to resume suspended transactions that have been marked rollback-only: This is provided by WebLogicJtaTransactionManager. Besides that special case, suspend/resume should work properly with Spring's standard JtaTransactionManager on WebLogic too (on both 8.1 and 7.0).
>
>* Suspend/resume via the JTA TransactionManager needs to be tested thoroughly on various J2EE servers: Currently known to work are Resin, JBoss, Orion/OC4J, JOnAS/JOTM, WebSphere 4.0, WebLogic 8.1 (with the above special treatment). To be tested: WebSphere 5.x, WebLogic 7.0.
>
>
>Spring's JtaTransactionManager within EJB CMT:
>
>* Using direct JTA within EJB CMT is not covered by standard J2EE: Effectively, it is clearly forbidden by the EJB spec. This applies directly to Spring's JtaTransactionManager within EJB CMT, no matter if just touching the JTA UserTransaction or the JTA TransactionManager too.
>
>* Nevertheless known to work on WebLogic 8.1, including transaction suspension. Known to work on WebLogic 7.0 too, except for transaction suspension. Most important ones to test: WebSphere 4.0 and 5.x. Of course, this scenario remains outside of the J2EE spec: Explicit support needs to be checked for each vendor.
>
>
>In total, the situation with direct JTA (no EJB CMT) is quite good: In such a scenario, most J2EE servers work properly with JtaTransactionManager's suspend/resume out-of-the-box (see above); I assume that WebSphere 5.x will work too. It seems that only WebLogic causes trouble here, and just in a special case...
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of jürgen höller [werk3AT]
>Sent: Thursday, September 02, 2004 4:35 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] JTA transaction suspension on
>WebSphere
>
>
>  
>
>>Isn user transaction object available trough bean context wrapper?
>>    
>>
>
>Only for BMT, according to the EJB spec:
>
>"The getUserTransaction method returns the javax.transaction.UserTransaction
>interface. The instance can use this interface to demarcate transactions and to obtain transaction status. Only instances of a session bean with bean-managed transaction demarcation can use this method."
>
>According to the spec, CMT beans are not supposed to touch direct JTA at all, not even the UserTransaction. While that still might work on some containers, you're outside the EJB spec here. And according to the BEA docs, WebLogic just officially supports the JTA TransactionManager for BMT too...
>
>
>  
>
>>>So I recommend to *either* work with EJB CMT *or* Spring-managed
>>>transactions. Do not try to combine both unless you're aware that
>>>you're violating the EJB spec. 
>>>      
>>>
>
>  
>
>>Hey, that was my point! :-)
>>    
>>
>
>OK, I admit I stole it, ehm, came to the same conclusion on my own ;-) However, it's important to explicitly state that using Spring-managed transactions with suspend/resume via the JTA TransactionManager *is* officially supported on WebLogic, for EJB BMT and web components.
>
>
>  
>
>>>However, EJB BMT with Spring-managed
>>>transactions should work nicely, even if involving the JTA
>>>TransactionManager on WebLogic.
>>>      
>>>
>
>  
>
>>I wonder if anyone tested it?
>>    
>>
>
>I assume that it works with BMT on WebLogic 8.1, as it even works with CMT there. According to the BEA docs, it should work with BMT on WebLogic 7.0: This is explicitly stated there. They don't mention using JTA within EJB CMT, though, so I assume that combo is not officially supported.
>
>
>  
>
>>Anyway using BMT does not have much value, especially with MDB's and 
>>I believe it will also increase risks of losing data in case of 
>>container failures/crashes (XA transaction manger use heuristics in this 
>>case and should roll back everything correctly).
>>    
>>
>
>Effectively, MDBs should be the only problem, as we can't do transactional message reception without CMT there.
>
>With BMT session beans or web components, Spring-managed transactions with JtaTransactionManager should be as powerful as CMT session beans, including transaction suspension and full recovery capabilities (which are provided by the JTA transaction manager, not by the EJB container).
>
>
>  
>
>>So, now it is unclear if it does work on WLS 8 in CMT scenario?
>>    
>>
>
>Thomas just clarified that he indeed tested this on CMT, so it does work with CMT on WebLogic 8. That combo still outside of the EJB spec, though.
>
>
>Juergen
>
>
>  
>
>>-----Original Message----- From:
>>spr...@li... 
>>[mailto:spr...@li...]On
>>Behalf Of Eugene Kuleshov Sent: Thursday, September 02, 2004 1:23 PM 
>>To: spr...@li... Cc: Dmitri
>>Maximovich Subject: Re: [Springframework-developer] JTA transaction
>>suspension on WebSphere
>>
>>
>>Juergen,
>>
>>If I'm reading this correctly, JTA transaction manager interface in
>>Weblogic available to beans that are managing transactions
>>themselves, but not suppose to be used by beans under CMT.
>>
>>regards, Eugene
>>
>>
>>
>>    
>>
>>>A further update: I've just discovered that WebLogic even
>>>officially supports javax.transaction.TransactionManager as public
>>>API!
>>>
>>>http://e-docs.bea.com/wls/docs70/jta/jtaapi.html
>>>
>>>"Client-initiated transactions-the JTA transaction manager
>>>interface (javax.transaction.TransactionManager) is made available
>>>to clients and bean providers through JNDI. This allows clients and
>>>EJBs using bean-managed transactions to suspend and resume
>>>transactions."
>>>
>>>They only interpret the semantics of resume a bit differently, i.e.
>>>not automatically resuming a transaction that has been marked
>>>rollback-only. They explicitly offer their proprietary forceResume
>>>method for this. It's quite clearly a bug then that it doesn't work
>>>in WebLogic 7.0: We could even try to report that to BEA! It does
>>>work in WebLogic 8.1, though...
>>>
>>>So in principle, suspend/resume via the JTA TransactionManager *is*
>>> supported by WebLogic, just with special semantics. And if you
>>>need the forceResume semantics, you can use Spring's new 
>>>WebLogicJtaTransactionManager. Essentially, the JTA spec should be
>>>clearer about the semantics of TransactionManager.resume here...
>>>
>>>      
>>>
>>    
>>
>>>________________________________
>>>
>>>Von: spr...@li... im
>>>Auftrag von jürgen höller [werk3AT] Gesendet: Mi 01.09.2004 22:01
>>>An: spr...@li... Betreff: Re: 
>>>[Springframework-developer] JTA transaction suspension on WebSphere
>>>
>>>
>>>
>>>
>>>An update: The issue was indeed caused by Spring's transaction 
>>>synchronization in combination with EJB CMT transaction suspension.
>>>Once you turn off Spring's transaction synchronization, which
>>>causes our Hibernate support to fall back to direct JTA
>>>synchronization, everything works nicely. I've also refined our
>>>Hibernate LOB types to be able to work with direct JTA
>>>synchronization too, so that our full Hibernate support works in
>>>such a scenario without hassle.
>>>
>>>Furthermore, Victor was so kind to test a variety of combinations
>>>with Spring-driven JTA transaction suspension on WebSphere, among
>>>those with an outer transaction that has been marked rollback-only
>>>(which doesn't work out-of-the-box on WebLogic). Fortunately,
>>>everything worked nicely!
>>>
>>>Thus, it's now quite safe to assume that WebSphere's JTA
>>>TransactionManager is fully compatible with Spring, at least on
>>>WebSphere 4. It would be good to get some tests on WebSphere 5 -
>>>any volunteers? This means, to the best of our current knowledge,
>>>that we only need special handling (WebLogicJtaTransactionManager)
>>>on WebLogic, and that the only container where suspend/resume
>>>doesn't work in all cases is WebLogic 7.
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im
>>>Auftrag von jürgen höller [werk3AT] Gesendet: Di 31.08.2004 10:58
>>>An: spr...@li... Betreff: Re: 
>>>[Springframework-developer] JTA transaction suspension on WebSphere
>>>
>>>
>>>
>>>
>>>Indeed, Thomas: I've pointed out exactly the same to Eugene on that
>>> WebLogic issue in JIRA.
>>>
>>>FYI, I've just noticed that I might have misinterpreted Victor's
>>>problem last night: He doesn't use Spring transactions with
>>>REQUIRES_NEW, but rather an outer Spring transaction plus an inner
>>>EJB CMT transaction with REQUIRES_NEW. Spring's
>>>JtaTransactionManager never touches the JTA TransactionManager is
>>>such a scenario, so it can't be caused by the suspend/resume
>>>interaction there.
>>>
>>>I rather suspect that the problem is Spring's transaction
>>>synchronization, which gets activated for the outer Spring
>>>transaction, but doesn't get notified of the transaction suspension
>>>caused by the inner EJB CMT transaction. Therefore, Spring's
>>>Hibernate support within the inner transaction will still
>>>synchronize with the outer Spring transaction, flushing the
>>>Hibernate Session at completion of the *outer* rather than the 
>>>inner transaction.
>>>
>>>The solution I've suggested is to turn off Spring's transaction 
>>>synchronization in that case. It should always be turned off when
>>>using transaction suspension driven by EJB CMT. See my JIRA
>>>comments:
>>>
>>>http://opensource.atlassian.com/projects/spring/browse/SPR-295
>>>
>>>As I've noted there, it would still be interesting whether
>>>Spring-driven JTA transaction suspension works with WebSphere:
>>>i.e., a Spring transaction demarcation with REQUIRES_NEW in case of
>>>an existing transaction. We might still face problems there, of
>>>course, but it seems to me that Victor's issue is not an indication
>>>for those.
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im
>>>Auftrag von Thomas Risberg Gesendet: Di 31.08.2004 06:33 An: 
>>>spr...@li... Betreff: Re: 
>>>[Springframework-developer] JTA transaction suspension on WebSphere
>>>
>>>
>>>
>>>
>>>This is not an issue for transactions declared with REQUIRED,
>>>SUPPORTS, MANDATORY or NEVER.  For these transactions there is no
>>>need to mess with the JTA TransactionManager to suspend the current
>>>transaction. UserTransaction is sufficient for these and this
>>>should be portable between containers.
>>>
>>>The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we
>>>have to bend the rules and use the JTA TransactionManager API if it
>>>is available. This is where things break down since the appservers
>>>don't seem to cooperate.  Even WebLogic 8.1 did not work until we
>>>used a WebLogic specific API call (forceResume).
>>>
>>>Thomas
>>>
>>>
>>>Colin Sampaleanu wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>Eugene Kuleshov wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Colin Sampaleanu wrote:
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>'Eu' on his blog 3-4 days ago commented based on my own blog
>>>>>>entry, and a forum message: 
>>>>>>http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from
>>>>>> that section / C.2.4 /of the EJB spec says that the
>>>>>>container, for EJBs, must implement the UserTransaction
>>>>>>interface (and JTA 1.0.1) extension, but doesn't have to
>>>>>>implement the other interfaces defined in the JTA
>>>>>>specification. Fine, I've actually seen that before, 
>>>>>>coincidentally, when I was tracking something down a while
>>>>>>ago, but I think a container is fundamentally broken if it
>>>>>>_does_ expose the JTA TransactionManager interface, and it
>>>>>>doesn't behave as per the spec. The spec for an API is the
>>>>>>spec for the API. If you expose the interface at all, then
>>>>>>you need to expose it correctly... That's essentially how I
>>>>>>read that clause, and how I see things. In any case, I hope
>>>>>>the situation is going to improve, certainly WLS 8 works 
>>>>>>where WLS 7 doesn't, with out WL specific adapter...
>>>>>>            
>>>>>>
>>>>>
>>>>>Perhaps I wasn't clear enough. My point is that it is a bad
>>>>>idea to mix usage of JTA interface with declarative container
>>>>>managed transacttions for EJBs. In other words it is probably
>>>>>to use Spring JTA helpers/wrappers in web layer which is not
>>>>>using EJB's.
>>>>>
>>>>>Anyway it would be good have some more advanced tests to ensure
>>>>>that JTA actually work in WLS8 (and other containers) in case
>>>>>of failure/rollback with multiple XA resources involved into
>>>>>transaction (especially resources from different vendors, such
>>>>>as Oracle, Sybase, MQSeries).
>>>>>          
>>>>>
>>>>I fully agree about the tests. This is part of the reason I
>>>>created the ejbtest integration sample. Hopefully we will keep
>>>>adding to it.
>>>>
>>>>As for the clause in question, it says:
>>>>
>>>>"The EJB container must include the JTA 1.0.1 extension, and it
>>>>must provide the javax.transaction.UserTransaction interface to
>>>>enterprise beans with bean-managed transaction demarcation
>>>>through the javax.ejb.EJBContext interface, and also in JNDI
>>>>under the name java:comp/UserTransaction, in the cases required
>>>>by the EJB specification. The other JTA interfaces are low-level
>>>>transaction manager and resource manager integration interfaces,
>>>>and are not intended for direct use by enterprise beans.
>>>>
>>>>This is unfortunately not worded very well in my opinion, in
>>>>terms of being very clear about CMT. Consider that this is the
>>>>section of the spec called 'The Container Provider's
>>>>Responsibility'. It is about the minimum set of services which
>>>>the container must provide to the EJB. I do not equate anything
>>>>in the paragraphs above as saying (with any adequate level of
>>>>clarity) that if the container chooses to expose other APIs the 
>>>>EJB _is not_ allowed to use them. I read the last sentence as a 
>>>>justification as to _why_ the container doesn't have to provide
>>>>the other JTA interfaces. The spec is actually very specific
>>>>about what EJBs may and may not do, consider threading for
>>>>example. Again, my opinion is that if the container does choose
>>>>to expose an API like JTA's TransactionManager, then it has to
>>>>behave correctly, as an API is an API.
>>>>
>>>>
>>>>Ultimately, only the spec writers know what they really intended,
>>>>and I agree that people wanting to move an app from container to
>>>>container, and from app server version to version, are not going
>>>>to get as predictable results in a CMT+Spring Transaction setup
>>>>as they would in a CMT alone, or Spring Tx alone setup. That
>>>>said, it can still be a viable and useful combination. Over a
>>>>period of some months, I migrated an app on JBoss from CMT EJB to
>>>>no EJB with Spring Tx wrapping service beans, and the CMT+Spring
>>>>Tx combo provided a valuable middle ground in the migration, in
>>>>the perdio when there were still some EJBs, but a lot had already
>>>> moved over.
>>>>
>>>>Regards, Colin
>>>>        
>>>>