Hi Juan
Thanks a lot for the reply.
I have one doubt that when you specify the second part of the example where
you call the method m2 two times
SFSB mySFSB = mySFSBHome.create();
mySFSB.m2();
mySFSB.m2(); //tries to start a new TX without committing/rollbacking
the current TX.
How do you predict that it tries to start the new transaction
For example if I say that I'm using the container managed transactions then
when the first method returns the transaction would have completed , isn;t
it .
And Also From the Book Enterprise JavaBeans 2.0 by Richard Monsoon Haefel
This also complies with what the EJB Specs says
Chapter 14 Transactions
Sub Section : Life in the Transactional Method Ready State
The text goes like this
Once a stateful session bean is a part of transaction - whether it
implements SessionSynchronization or not -
It can not be accessed by any other transactional context. This is true
regardless of whether the client tries to
access the EJB with a different context or the EJB's own method creates a
new context.
If, for example , a method with a transaction attribute of RequiresNew is
invoked, the new transactional
context causes an error to be thrown. Since the not supported and Never
attributes specify a different transactional
context ( no context ) , invoking a method with these attributes causes an
error.
Regards
Hemant
Juan Pablo
Lorandi To: [EMAIL PROTECTED]
<rifle@CODEFOUNDR cc:
Y.COM> Subject: Re: Transaction Doubt
Sent by: A
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@JAV
A.SUN.COM>
08/20/02 05:41 AM
Please respond to
Juan Pablo
Lorandi
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".
-----------------------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".
