• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

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

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 354
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Do not start a transaction in t. But then you will use the 'guaranteed' atomicity.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic