Menu
▾
▴
Re: [Springframework-developer] JTA transaction suspension on WebSphere
|
From: eu <eu...@md...> - 2004-09-02 13:58:48
|
jürgen höller [werk3AT] wrote: > 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. Isn user transaction object available trough bean context wrapper? > 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. Hey, that was my point! :-) > However, EJB BMT with Spring-managed > transactions should work nicely, even if involving the JTA > TransactionManager on WebLogic. I wonder if anyone tested it? Anyway using BMT does not have much value, especially with MDB's and I believe it will also increase risks of losing data in case of container failures/crashes (XA transaction manger use heuristics in this case and should roll back everything correctly). > 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... So, now it is unclear if it does work on WLS 8 in CMT scenario? regards, Eugene > -----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 |
