Menu
▾
▴
Re: [Springframework-developer] JTA transaction suspension on WebSphere
|
From: Thomas R. <tho...@tr...> - 2004-09-02 13:40:32
|
I was using CMT with 8.1sp2. Thomas jürgen höller [werk3AT] wrote: >Thomas, can you confirm whether you used CMT or BMT in your tests on WebLogic 8.1? If it was BMT, can you check whether you get a strange NullPointerException with CMT, like Eugene gets on WebLogic 7.0? > >Eugene, it would be great if you could check whether "forceResume" works with BMT on WebLogic 7.0. We need to document behavior with BMT clearly. Judging from the BEA docs, this should work with BMT; if not, it's WebLogic bug. > >>From my point of view, we do not officially support Spring transactions within EJB CMT in the first place, as any use of JTA (no matter whether UserTransaction or TransactionManager) is forbidden within CMT. Correct me if I'm wrong, of course! > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of jürgen höller [werk3AT] >Sent: Thursday, September 02, 2004 2:58 PM >To: spr...@li... >Subject: Re: [Springframework-developer] JTA transaction suspension on >WebSphere > > >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! >> >>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 >>> >>> > > > >------------------------------------------------------- >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=5047&alloc_id=10808&op=click >_______________________________________________ >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_id808&op=ick >_______________________________________________ >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_id808&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > |
