Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED]
Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com First, I appreciate a lot the recognition, but I think you give me way too much credit; my advice is seldom precious. But thanks anyway, it makes lots for my self-steem :-D OK, first, the first question: > Is that correct ??? Meaning if I call another tx method with different TX attribute, an error is thrown?; it is sligthly incorrect; if I have a SFSB with methods: m1() //REQUIRED m2() //REQUIRES_NEW m3() //NOT_SUPPORTED This sequence is perfectly valid(assuming no commit or rollback is issued within these methods): ... SFSB mySFSB = mySFSBHome.create(); mySFSB.m3(); mySFSB.m2(); mySFSB.m1(); ... This sequence is not valid (again, assuming no commit or rollback is issued): ... SFSB mySFSB = mySFSBHome.create(); mySFSB.m2(); mySFSB.m2(); //tries to start a new TX without committing/rollbacking the current TX. ... Why? Because once a TX has been started the bean goes from the method-ready state into the method-ready-in-tx state-- the only(desirable) way to enroll in a new transaction or no transaction at all is to exit the current transaction, and that is achieved only by issuing commit() or rollback() (Ref section 7.6 in EJB 2.0, STATEFUL Session Bean State Diagram). The other way is to ERROR and killing the instance(not my first choice ;-) ). The spec defines this behavior in such a way that allows Container Providers to optimize the serialization of a SFSB by using techniques different from Java Serialization, and also to make the conversational state of a SFSB survive across transactional borders. Section 7.4 discusses CONVERSATIONAL State in detail. Conversational state(vastly simplified, the fields of a SFSB instance) must be maintained(by the container, that is) across methods and transactions. This enables better caching of tx-aware resources(altough crossing TX boundaries, the burden of keeping data synch'ed is beared by the Bean code). Always bear in mind that since SB are issued to a client, and a single client alone, these provissions are made for caching data for a single client. Using a SFSB, one can often avoid using TX Sagas, for instance, which aren't unusual in CORBA and MTS, specially in data-warehousing software and in shopping carts. The timeout of the LRU algorithm(until the SFSB is passivated) and the timeout between the passivation and the automatic destruction of the SFSB(into the does not exist state) also come into play here. Finally, the statement is true regardless of the actual implementation of the SessionSynchronization interface. The purpose of SessionSynchronization is to make a SFSB instance aware of the status of the current transaction. It only applies to SFSB(retain conversational state) that use CMT(implying the SFSB doesn't completely control the TX). If you're using Bean Managed Transactions, you do not need to implement SessionSynchronization to achieve the same results, and the behavior remains unchanged. My 2c, (and hoping somebody else helps me to make my babble more clear) Juan Pablo > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of Hemant Arora > Sent: Monday, August 19, 2002 12:42 PM > To: [EMAIL PROTECTED] > Subject: Transaction Doubt > > > Hi All > > Anybody please clarify this doubt . > > Juan Pablo Lorandi , your valueable and precious advise can > make my doubt clear..... > > Senario is > > A stateful session bean implements SessionSynchronization. > If a client invoked a transactional method on the bean, the > method is in transaction ready state now if the client > invoked another transactional method whose deployment > descriptor transaction attribute is different from that of > the first method then there wil be error thrown as EJB 2.0 Specs says. > > Is that correct ??? > > Is it due to the fact that bean is implementing the > SessionSynchronization and the container has issued > afterBegin call , that's why or this statement is true if > the bean is not implementing this interface. > > > From the EJB Specs > > Section 7.6 STATEFUL Session Bean State Diagram > > " Session bean methods invoked by the client in this > transaction can now be delegated to the bean instance. An > error occurs if a client attempts to invoke a method on the > session object and the deployment descriptor for the method > requires that the container invoke the method in a different > transaction context than the one with which the instance is > currently associated or in an unspecified transaction context. " > > Thanks > Hemant > > -----------------------Disclaimer------------------------ > > The views of the author may not necessarily reflect those > of the Company. All liability is excluded to the extent > permitted by law for any claims arising as a result of the > use of this medium to transmit information by or to IT > Solutions (India) Pvt. Ltd. > > We have taken precautions to minimize the risk of > transmitting software viruses, but we advise you to > carry out your own virus checks on any attachment to > this message. We cannot accept liability for any loss or > damage caused by software viruses. > > ------------------------Disclaimer------------------------ > > ============================================================== > ============= > 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". > =========================================================================== 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".
