Please read inline comments.
Regards,
Hemant
Server Team,
Pramati Technologies
www.pramati.com
----- Original Message -----
From: "krithikav" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 23, 2001 3:25 PM
Subject: Doubt in Transaction attributes
Hi,
I have two queries.
1.I read in a book that once we invoke a method on a bean with the
transaction attribute(TX_BEAN_MANAGED), then we cannot call another method
that would involve it in a different transaction(or no transaction). If we
try to do that a java.rmi.RemoteException will be thrown.
<Hemant>
A bean with a transaction attribute TX_BEAN_MANAGED cannot start a
transaction while the instance has not committed the previous transaction.
The book is correct !!!
</Hemant>
But I was able to
invoke methods of beans with transaction attribute(TX_BEAN_MANAGED,
TX_NOT_SUPPORTED, TX_REQUIRED etc) from a method of a bean with transaction
attribute (TX_BEAN_MANAGED). Can you explain which is correct - what I read
in the book or what worked programatically for me( I am just worried if I
have made any mistake in the program and thatz why it is working)
<Hemant>
The restriction is for the same bean in a transaction. Here from a
TX_BEAN_MANAGED transactional bean you are calling other beans with
different transaction attributes. You are having the right kind of
experiences !!!
</Hemant>
2. This query is related to the one above. A manual says that when a
bean(say BeanA) with transaction attribute TX_BEAN_MANAGED calls a method of
another bean(say BeanB), the transaction context is only associated with the
bean that started it(that is Bean A) and not with the calling thread and it
will not be managed by the container of BeanB.
So I understood that the changes to the database from BeanB method will
always be committed even if the BeanA rollsback. However when I tried to
verify it through my program, the database changes from BeanB commits if has
a transaction attribute (TX_NOT_SUPPORTED) and it is rolledback when it has
a transaction attribute(TX_REQUIRED) if the BeanA rollsback. Does this mean
that the BeanA's transaction context was propogated to BeanB?
<Hemant>
Regardless whether an enterprise bean uses bean-managed or
container-managed transaction demarcation,
the burden of implementing transaction management is on the EJB Container
and Server Provider. Again the experience is absolutely right !!!!
</Hemant>
Regards,
Krithika
===========================================================================
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".
