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

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

We need to make the distinction in our docs between using Spring 
transactions, and actually turning on synchronization to the Spring tx 
manager. I don't think most people realize the latter is possible, or 
the consequences...

jürgen höller [werk3AT] wrote:

>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
>>    
>>