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

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

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

________________________________

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.=20
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
>
>
>
>
> -------------------------------------------------------
> 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_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer