aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Rollback Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Rollback" Watch "Rollback" New topic
Author

Rollback

Oliver Rensen
Ranch Hand

Joined: Jul 23, 2004
Posts: 109

Hi,

when a stateless session bean method throws a system-exception, the transaction will be rolled back. But when I catch the system-exception and rethrow an application-exception to the client, will the transaction still be rolled back?



Does this code lead to a rollback?

Kind regards
Oliver
Ravi kanth P M
Greenhorn

Joined: Jul 05, 2006
Posts: 4
The rollback depends on how you define your application exception. If you are using EJB 3.0, you have provision to set rollback=true or false using annotation @Application Exception.

If the rollback is set to true for your application, then the Transaction will rollback.
Duran Harris
Ranch Hand

Joined: Nov 09, 2008
Posts: 598

and in EJB2.x ?


===>SCJP 1.5(72%)<===
==>SCWCD1.5(76%)<===
Devaka Cooray
ExamLab Creator
Saloon Keeper

Joined: Jul 29, 2008
Posts: 3268
    
  52

Duran Harris wrote:and in EJB2.x ?

In EJB 2.x, an application exception does not cause the container to roll back a transaction automatically.


Author of ExamLab ExamLab - a free SCJP / OCPJP exam simulator
What would SCJP exam questions look like? -- Home -- Twitter -- How to Ask a Question
Oliver Rensen
Ranch Hand

Joined: Jul 23, 2004
Posts: 109

The following is an excerpt from the book "Pro EJB 3". I like this book very much, but the following example is one of the few things that I have problems to understand:



The book says:
"The ChangeCollisionException class is annotated with @ApplicationException, which is an EJB 3.0 containter annotation in the javax.ejb package to indicate to the container that the exception is not really a system-level exception but should be thrown back to the client as is. Normally, defining an application exception will cause the container to not roll back the transaction, but this is an EJB 3.0 container notion. The persistence provider that threw OptimisticLockException does not know about the special semantics of designated application exceptions and seeing a runtime exception will go ahead and mark the transaction for rollback."

And the spec says:
" An application exception does not automatically result in marking the transaction for rollback unless the
ApplicationException annotation is applied to the exception class and is specified with the
rollback element value true or the application-exception deployment descriptor element
for the exception specifies the rollback element as true."

In the above example the ApplicationException annotation has no rollback element set to true. I do not understand why "throw new ChangeCollisionException()" causes the transaction to roll back.
Duran Harris
Ranch Hand

Joined: Nov 09, 2008
Posts: 598

Somebody can comment on this??
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10289
    
168

Oliver Rensen wrote:

In the above example the ApplicationException annotation has no rollback element set to true. I do not understand why "throw new ChangeCollisionException()" causes the transaction to roll back.


It doesn't rollback the transaction. The text you posted doesn't say the transaction is rolled back.
Duran Harris
Ranch Hand

Joined: Nov 09, 2008
Posts: 598

But it says that the persistence provider will mark the transaction for rollback:

Normally, defining an application exception will cause the container to not roll back the transaction, but this is an EJB 3.0 container notion. The persistence provider that threw OptimisticLockException does not know about the special semantics of designated application exceptions and seeing a runtime exception will go ahead and mark the transaction for rollback
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10289
    
168

Duran Harris wrote:But it says that the persistence provider will mark the transaction for rollback:

Normally, defining an application exception will cause the container to not roll back the transaction, but this is an EJB 3.0 container notion. The persistence provider that threw OptimisticLockException does not know about the special semantics of designated application exceptions and seeing a runtime exception will go ahead and mark the transaction for rollback


Because OptimisticLockException is not marked as a @ApplicationException. It's the ChangeCollisionException which is marked as an @ApplicationException. That's the reason why the OptimisticLockException is being explicitly caught by the bean and converted to a ChangeCollisionException, to avoid the rollback from happening.
Duran Harris
Ranch Hand

Joined: Nov 09, 2008
Posts: 598

Ah I see....Thanks for clearing that up.Wasn't paying attention there.
Oliver Rensen
Ranch Hand

Joined: Jul 23, 2004
Posts: 109

Jaikiran, thank you for the help.
Duran Harris
Ranch Hand

Joined: Nov 09, 2008
Posts: 598

So I would be right if I summarized it as :

EJb 3.0 application exception:doesnt rollback(can force rollback with attribute)
EJb 3.0 system exceptions:causes rollback

EJB 2.x application exception:doesnt rollback(can't be forced)
EJB 2.x system exception causes rollback
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Rollback