• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Rollback

 
Oliver Rensen
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 608
Eclipse IDE Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
and in EJB2.x ?
 
Devaka Cooray
ExamLab Creator
Marshal
Pie
Posts: 4323
236
Chrome Eclipse IDE Google App Engine IntelliJ IDE jQuery Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Oliver Rensen
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 608
Eclipse IDE Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Somebody can comment on this??
 
Jaikiran Pai
Marshal
Pie
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 608
Eclipse IDE Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 608
Eclipse IDE Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah I see....Thanks for clearing that up.Wasn't paying attention there.
 
Oliver Rensen
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jaikiran, thank you for the help.
 
Duran Harris
Ranch Hand
Posts: 608
Eclipse IDE Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic