File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Calling methods with TransactionAttributeType.REQUIRED --> transaction rolled back? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Calling methods with TransactionAttributeType.REQUIRED --> transaction rolled back?" Watch "Calling methods with TransactionAttributeType.REQUIRED --> transaction rolled back?" New topic
Author

Calling methods with TransactionAttributeType.REQUIRED --> transaction rolled back?

Agoston Bejo
Greenhorn

Joined: Nov 23, 2007
Posts: 8
Hi!

I've got the following problem: (Explanation follows after the example)

(Not a quite real example, just wrote it off the top of my head based on the real-world example, but it demonstrates the problem...)




The exception is:

javax.ejb.EJBTransactionRolledbackException: EJB Exception: ;
nested exception is: javax.ejb.TransactionRolledbackLocalException: EJB
Exception: ;
nested exception is:
weblogic.transaction.internal.AppSetRollbackOnlyException:
setRollbackOnly called on transaction;


Explanation:
If I'm inside a transaction context and call two methods after each
other that have TransactionAttributeType.REQUIRED specified and the
first one of which throws an exception: the second one cannot be called
anymore even if you handle the exception from the first one.

Apparently when the exception is thrown from the first one, it closes
the transaction it is in, which is the enclosing transaction, i.e. the
transaction the enclosing method, t() runs in. In my opinion this is not
correct, but as I cannot change JTA, the question is more like: is there
a workaround?

TransactionAttributeType.REQUIRES_NEW is not really an option, because
that would mean that if t1() doesn't throw an exception, it will commit
the changes it has made to the DB immediately when it returns, which is
obviously not what I want. (Which would be to run t() in a big
transaction that commits if and only if t() didn't throw an exception.)

Any ideas, anyone?

Thanks,
Agoston
Abhinav Srivastava
Ranch Hand

Joined: Nov 19, 2002
Posts: 349

Do not start a transaction in t. But then you will use the 'guaranteed' atomicity.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Calling methods with TransactionAttributeType.REQUIRED --> transaction rolled back?