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

[<jue...@we...>]

That's correct: good point. I'll point that out in the docs.

My main point was that BEA officially supports the JTA =
TransactionManager interface, so we're allowed to work with it and rely =
on it. That's a good thing and clearly shows BEA's intentions (for =
example, that it should officially work on WebLogic 7 too)! However, =
this admittedly just applies to web components and EJB BMT.

To the best of my knowledge, *no* JTA work is allowed within EJB CMT: =
neither on the UserTransaction nor on the TransactionManager. Many tools =
violate that principle (for example, Hibernate and JDO when registering =
JTA synchronizations), but that's still what the EJB spec says. I'll =
clarify that in our docs.

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. However, EJB BMT with Spring-managed =
transactions should work nicely, even if involving the JTA =
TransactionManager on WebLogic.

Unfortunately, I didn't notice earlier that you're working with EJB CMT. =
Does JtaTransactionManager's suspend/resume work with EJB BMT on =
WebLogic 7.0? That is, does that strange NullPointerException in =
WebLogic code occur with BMT too? I assume that Thomas did his tests on =
WebLogic 8.1 (where "forceResume" works) with EJB BMT...

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!
>=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
> WebLogicJtaTransactionManager. Essentially, the JTA spec should be =
clearer
> about the semantics of TransactionManager.resume here...
>=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:
> [Springframework-developer] JTA transaction suspension on WebSphere
>=20
>=20
>=20
> 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.
>=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:
> [Springframework-developer] JTA transaction suspension on WebSphere
>=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
> inner transaction.
>=20
> 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:
>=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:
> spr...@li... Betreff: Re:
> [Springframework-developer] JTA transaction suspension on WebSphere
>=20
>=20
>=20
> This is not an issue for transactions declared with REQUIRED, =
SUPPORTS,=20
> MANDATORY or NEVER.  For these transactions there is no need to mess =
with
> the JTA TransactionManager to suspend the current transaction.=20
> 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
>> Eugene Kuleshov wrote:
>>=20
>>=20
>>> Colin Sampaleanu wrote:
>>>=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=20
>>>> that section / C.2.4 /of the EJB spec says that the container, for=20
>>>> EJBs, must implement the UserTransaction interface (and JTA 1.0.1)=20
>>>> 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...
>>>=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=20
>>> failure/rollback with multiple XA resources involved into =
transaction=20
>>> (especially resources from different vendors, such as Oracle, =
Sybase,=20
>>> 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=20
>> provide the javax.transaction.UserTransaction interface to  =
enterprise=20
>> beans with bean-managed transaction demarcation through the=20
>> javax.ejb.EJBContext interface, and also in JNDI under the name=20
>> java:comp/UserTransaction, in the cases required by the EJB=20
>> 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
>> 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.
>>=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