Transactions & Exception doubt

[Chaminda Amarasinghe]

Hi Guys,

Can someone plss explain this scenario,
My target is to replicate how to correct errors and recall the ejb without discarding

There are 3 SLSBs named SlsbOne,SlsbTwo and SlsbThree,
SlsbThree is a bean managed tx,
Other 2 has Required tx attribute.
SlsbOne has 2 methods one throws unchecked application exception marked for rollback and other doesnt.
SlsbThree calles SlsbTwo.
SlsbTwo first calls SlsbOne's app exp throwing method in try block and in catch block calls the SlsbOne's plain method (That is, in an error i correct and recall)

I presumed in above scenario, I should not get any exception in SlsbThree and there should not be any bean discarding

But I get EJBException. It opens 2 doubts

1. Why I get exceptions, Since I have caught exception in SlsbTwo
2. Why I get EJBException instead of EJBRolledBackException in SlsbThree. (All are in same transaction created by SlsbThree)

And both SlsbTwo and SlsbThree have been discarded


Please help

Thank
Cham

[ November 08, 2008: Message edited by: Chaminda Amarasinghe ]
[ November 08, 2008: Message edited by: Chaminda Amarasinghe ]

[Ralph Jaus]

Hi Cham,

thanks for sharing this interesting scenario. I tried to imitate it and could figure out the following behavoir (used glassfish app server):

1. SlsbTwo calls a method from SlsbOne that throws an application exception.

2. Since the application exception's rollback-attribute is set to true, the container marks the transaction for rollback.

3. The application exception is catched in SlsbTwo.

4. SlsbTwo calls the plain method of SlsbOne

5. The transaction attribute of this method is REQUIRED and it runs in the caller's context. But in this transaction context the transaction is already marked for rollback. Therefore processing the method doesn't make sense and the container throws an TransactionRolledbackLocalException (= system exception).

6. Now we are in the situation of the second row in table 14 of the core spec, 14.3.1 (page 360): The container logs the system exception, discards SlsbOne's instance and throws an EJBTransactionRolledbackException.

7. SlsbTwo receives the EJBTransactionRolledbackException in the catch-block. Since this exception isn't catched (-> this should answer your first question) and because it's a system exception we are again in the situation of step 6: after logging, SlsbTwo's instance is discarded and an EJBTransactionRolledbackException is thrown.

8. SlsbThree receives the EJBTransactionRolledbackException.

9. The end depends on the exception handling in SlsbThree. If there is a single try-catch block in SlsbThree the EJBTransactionRolledbackException is catched there, probabliy leading to new problems because the user transaction isn't finished when the business method of SlsbThree finishes (see core spec 13.3.3).

Remarks:

a) If the rollback-attribute of the application exception is set to false everything works fine.

b) If the plain method in SlsbOne uses the transaction attribute REQUIRES_NEW everything works fine.

c) I'm not aware, if/where the situation in step 5 above is specified in the spec. I'll post it as a new item.
[ November 09, 2008: Message edited by: Ralph Jaus ]

[Chaminda Amarasinghe]

Hi Ralph,

Thanks for your time, and your clear explanation,

Can you try my other question as well in here

Thanks
Cham

Originally posted by Ralph Jaus:
Hi Cham,

thanks for sharing this interesting scenario. I tried to imitate it and could figure out the following behavoir (used glassfish app server):

1. SlsbTwo calls a method from SlsbOne that throws an application exception.

2. Since the application exception's rollback-attribute is set to true, the container marks the transaction for rollback.

3. The application exception is catched in SlsbTwo.

4. SlsbTwo calls the plain method of SlsbOne

5. The transaction attribute of this method is REQUIRED and it runs in the caller's context. But in this transaction context the transaction is already marked for rollback. Therefore processing the method doesn't make sense and the container throws an TransactionRolledbackLocalException (= system exception).

6. Now we are in the situation of the second row in table 14 of the core spec, 14.3.1 (page 360): The container logs the system exception, discards SlsbOne's instance and throws an EJBTransactionRolledbackException.

7. SlsbTwo receives the EJBTransactionRolledbackException in the catch-block. Since this exception isn't catched (-> this should answer your first question) and because it's a system exception we are again in the situation of step 6: after logging, SlsbTwo's instance is discarded and an EJBTransactionRolledbackException is thrown.

8. SlsbThree receives the EJBTransactionRolledbackException.

9. The end depends on the exception handling in SlsbThree. If there is a single try-catch block in SlsbThree the EJBTransactionRolledbackException is catched there, probabliy leading to new problems because the user transaction isn't finished when the business method of SlsbThree finishes (see core spec 13.3.3).

Remarks:

a) If the rollback-attribute of the application exception is set to false everything works fine.

b) If the plain method in SlsbOne uses the transaction attribute REQUIRES_NEW everything works fine.

c) I'm not aware, if/where the situation in step 5 above is specified in the spec. I'll post it as a new item.

[ November 09, 2008: Message edited by: Ralph Jaus ]