Transaction Attributes in EJB

[kapil kulkarni]

I have some doubts regarding setting transaction attributes for
EJB in deployment descriptor.
I explain the situation :
A session beans calls for inserting a new record in a table say X
table.
Method name is insertRow(some params);
This method is having transaction attribute as "requires". Now this method
calls 2 entity beans to insert new records. i.e. first new record is created
with "create" method of X entity bean. It's transaction attribute is
"requires". X table is master table. Now after this some data is
inserted into child table X_CHILD with X_ID as foreign key
(X_ID is primary key in X).
Now "create" method of XChild entity bean is used for this insertion
and its transaction attribute is "requires".
But if this method insertRow(..) of session bean gets executed, we are
getting exception as "parent key not found" while inserting records in
X_CHILD after inserting new record in X.
What should we do in this case ?
If we change transaction attribute of "create" method of X entity bean
to "requires new", we are not getting exception. But if there is some
exception while inserting row in X_CHILD and we get exception then
transaction gets rolled back but as transaction newly started for X entity beans
"create" method is commited it does not get rolled back ?
What should we do in this case ?
Thanks in advance for your help

[Joe McGuire]

Kapil,
You say your insertRow() method is in an EJB with a transaction attribute of TX_REQUIRED, which forces the EJB to be executed within a transaction � started either by the client, or else the container.
If you change it to TX_REQUIRES_NEW, this forces the EJB to execute within a new transaction started by the container.
In your scenario, you have a method called from within a transaction. The client�s transaction is therefore suspended for the duration of the call to the EJB, and the container starts its own localized transaction.
This is bad because if an error occurs within the EJB, the error localization will only be the container, when the clinet may need to know about it. The error, such as in your case, may still be occurring.
You can avoid this by using the TX_BEAN_MANAGED attribute, from which the client�s transaction is suspended, and the EJB�s takes over. This gives the developer the most flexibility, though a bit more work on your part is involved. The technical code is included within the EJB java implementation. Start by having your bean implement the java.jts.UserTransaction interface to demarcate transactions.
Hope that helps,
joe