Hi Laurel, In your reply you say that "The transaction is stateful session A is suspended when stateful session B takes over". Is this correct, should the transaction not be propagated to bean B? Should the behaviour not be the same as if bean B was CMT with a "Requires" attribute, i.e. it would participate in the outer transaction started be bean A?
Regarding multiple data sources, I do only have one. I also thought about timeout issues and re-tested the problem by changing bean B to be stateless. The same HeuristicMixedException occurs. Any other ideas? regards Bhupesh -----Original Message----- From: Laurel Neustadter [mailto:[EMAIL PROTECTED]] Sent: 31 October 2001 19:16 To: 'Bhupesh Wagjiani'; [EMAIL PROTECTED] Subject: RE: Transaction Propogation Hi Bhupesh: You asked: Am I correct in assuming that when I obtain a UserTransaction object (sessionContext.getUserTransaction) in bean B, this should be the same UserTransaction that is active from bean A? Answer: The transaction is stateful session A is suspended when stateful session B takes over. Are you updating multiple data sources in your transaction? A HeuristicMixedException occurs when some resource managers make the unilateral decision to commit or rollback after Phase 1 but before Phase II of the 2-phase commit protocol (i.e., they make a heuristic decision), and others make the opposite decision, or the decision doesn't match the decision of the transaction coordinator. If you are not updating multiple data sources, I wonder if stateful session bean B is timing out, and that could be causing the HeuristicMixedException. In either case, timing considerations may be the reason that sometimes you get the HeuristicMixedException and other times you don't. It is my understanding that chaining stateful session beans is considered to be bad practice, precisely because one could time out before the other. Why do you need to chain stateful session beans? (Anyone out there have opinions on chaining stateful session beans?) Laurel -----Original Message----- From: Bhupesh Wagjiani [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 31, 2001 4:31 AM To: [EMAIL PROTECTED] Subject: Transaction Propogation All, I'm after some clarification as to my understanding about how transaction propogation works. I have a Stateful session bean (A) with bean managed transactions. This bean obtains a UserTransaction object (sessionContext.getUserTransaction) and begins a transaction. It then calls various stateless session beans that actually insert/update data. These stateless beans have container managed transactions with a transaction attribute of Requires. Bean A then makes a call to another Stateful session bean (B). Bean B also obtains a UserTransaction object (sessionContext.getUserTransaction) and checks the STATUS. If there is already a transaction active it continues to call other stateless beans to update/insert records in the same way that bean A did. It then returns control back to beans A. If there isn't an active transaction it begins and commits/rollsback locally. The problem I have is that when I try to commit or rollback in bean A I sometimes get a javax.transaction.HeuristicMixedException. I'm a little confused as this problem seems to occur randomly even when using exactly the same data/sequence of events. When I call userTransaction.getStatus() in bean B this does return me what I expect (STATUS_ACTIVE) and I do not commit or rollback from bean B. Am I correct in assuming that when I obtain a UserTransaction object (sessionContext.getUserTransaction) in bean B, this should be the same UserTransaction that is active from bean A? Could this be a bug in my container or is what I'm trying to do not correct? regards Bhupesh Wagjiani =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". ******************************************************************************* Any opinions expressed in this email are those of the individual and not necessarily those of GamCom Solutions Ltd (herein after "GamCom") and/or its subsidiaries. This email and any files transmitted with it, including replies and forwarded copies (which may contain alterations) subsequently transmitted from GamCom and/or its subsidiaries, are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use is strictly prohibited; please notify us immediately and do not disclose, distribute, or retain this email or any part of it. We believe but do not warrant that this e-mail and any attachments are virus free. You must therefore take full responsibility for virus checking. GamCom and/or its subsidiaries reserve the right to monitor all email communications through their networks. If you have received this email in error please notify GamCom by telephone on +44 (0)20 8838 5441 or via email to [EMAIL PROTECTED] , including a copy of this message. ******************************************************************************* =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
