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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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=FCrgen h=F6ller [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.=20

> 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=20
> I believe it will also increase risks of losing data in case of=20
> container failures/crashes (XA transaction manger use heuristics in =
this=20
> 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...=20
> [mailto:spr...@li...]On
> Behalf Of Eugene Kuleshov Sent: Thursday, September 02, 2004 1:23 PM=20
> To: spr...@li... Cc: Dmitri
> Maximovich Subject: Re: [Springframework-developer] JTA transaction
> suspension on WebSphere
>=20
>=20
> Juergen,
>=20
> 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.
>=20
> regards, Eugene
>=20
>=20
>=20
>> A further update: I've just discovered that WebLogic even
>> officially supports javax.transaction.TransactionManager as public
>> API!
>>=20
>> http://e-docs.bea.com/wls/docs70/jta/jtaapi.html
>>=20
>> "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."
>>=20
>> 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...
>>=20
>> 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=20
>> WebLogicJtaTransactionManager. Essentially, the JTA spec should be
>> clearer about the semantics of TransactionManager.resume here...
>>=20
>=20
>=20
>>=20
>> ________________________________
>>=20
>> Von: spr...@li... im
>> Auftrag von j=FCrgen h=F6ller [werk3AT] Gesendet: Mi 01.09.2004 22:01
>> An: spr...@li... Betreff: Re:=20
>> [Springframework-developer] JTA transaction suspension on WebSphere
>>=20
>>=20
>>=20
>>=20
>> An update: The issue was indeed caused by Spring's transaction=20
>> 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.
>>=20
>> 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!
>>=20
>> 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.
>>=20
>> Juergen
>>=20
>>=20
>> ________________________________
>>=20
>> Von: spr...@li... im
>> Auftrag von j=FCrgen h=F6ller [werk3AT] Gesendet: Di 31.08.2004 10:58
>> An: spr...@li... Betreff: Re:=20
>> [Springframework-developer] JTA transaction suspension on WebSphere
>>=20
>>=20
>>=20
>>=20
>> Indeed, Thomas: I've pointed out exactly the same to Eugene on that
>>  WebLogic issue in JIRA.
>>=20
>> 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.
>>=20
>> 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=20
>> inner transaction.
>>=20
>> The solution I've suggested is to turn off Spring's transaction=20
>> synchronization in that case. It should always be turned off when
>> using transaction suspension driven by EJB CMT. See my JIRA
>> comments:
>>=20
>> http://opensource.atlassian.com/projects/spring/browse/SPR-295
>>=20
>> 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.
>>=20
>> Juergen
>>=20
>>=20
>> ________________________________
>>=20
>> Von: spr...@li... im
>> Auftrag von Thomas Risberg Gesendet: Di 31.08.2004 06:33 An:=20
>> spr...@li... Betreff: Re:=20
>> [Springframework-developer] JTA transaction suspension on WebSphere
>>=20
>>=20
>>=20
>>=20
>> 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.
>>=20
>> 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).
>>=20
>> Thomas
>>=20
>>=20
>> Colin Sampaleanu wrote:
>>=20
>>=20
>>=20
>>> Eugene Kuleshov wrote:
>>>=20
>>>=20
>>>=20
>>>> Colin Sampaleanu wrote:
>>>>=20
>>>>=20
>>>>=20
>>>>> 'Eu' on his blog 3-4 days ago commented based on my own blog
>>>>> entry, and a forum message:=20
>>>>> =
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,=20
>>>>> 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=20
>>>>> where WLS 7 doesn't, with out WL specific adapter...
>>>>=20
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> 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).
>>>=20
>>>=20
>>> 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.
>>>=20
>>> As for the clause in question, it says:
>>>=20
>>> "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.
>>>=20
>>> 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=20
>>> EJB _is not_ allowed to use them. I read the last sentence as a=20
>>> 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.
>>>=20
>>>=20
>>> 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.
>>>=20
>>> Regards, Colin

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer