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

[Eugene K. <eu...@pl...>]

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