• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Exceptions

 
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear all,

suppose a session bean with CMT and a business method that is performed in a newly started transaction. If the method throws an application exception there are two scenarios for the container's action (ejb core spec page 361, table 14, first row):

a) if setRollbackOnly() was called in the method, then rollback the transaction
b) if the application exception is specified as causing rollback, then mark the transaction for rollback.

Why behaves the container different in these cases ? That means, why doesn't the container rollback the transaction in b), too ?

Or is marking a transaction for rollback through the container the same as if the container performs a rollback ?
[ October 29, 2008: Message edited by: Ralph Jaus ]
 
Sheriff
Posts: 14691
16
Eclipse IDE VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

why doesn't the container rollback the transaction in b), too


You could have thrown a application exception whose rollback attribute was set to false : @ApplicationException(rollback=false). It's useful when you want to stop a process when an error occured, but you want the transaction to keep going.

In scenario a, the transaction was explicitly rolled back, so no matter what kind of application exception was thrown, the transaction will be rolled back.
 
Ralph Jaus
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Christophe,

in the described scenario b) the rollback attribute of the application exception is set to true. And then the spec says: The container marks the transaction for rollback.

But why doesn't the container perform the rollback directly as he does in a) ?
[ October 30, 2008: Message edited by: Ralph Jaus ]
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When calling setRollbackOnly, the container instructs the transaction manager to mark the transaction for rollback.
In b), setRollbackOnly is not called, so if the application exception is set to rollback the transaction, the container marks the transaction for rollback. In both cases, the transaction will finally be rolled back. I don't think you need to think too deeply about it
 
Ralph Jaus
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the explanation, Christophe.
reply
    Bookmark Topic Watch Topic
  • New Topic