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 Beginners question on EJB & transactions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Beginners question on EJB & transactions" Watch "Beginners question on EJB & transactions" New topic
Author

Beginners question on EJB & transactions

Adrian Bates
Greenhorn

Joined: Jun 01, 2005
Posts: 24
I am trying to write my first EJB using container managed transactions. I have defined the EJB and added a container transaction type of Required to it.

The EJB method adds records to 2 different database tables and when I force an error to occur with the 2nd insert it doesn't rollback the 1st.

Is there something else that I need to do? I assumed that if the method on the EJB exited with an exception then it would automatically rollback. Is this not right?

Thanks in advance,
Adrian
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
Rollback will occur if a system exception is thrown from your bean code to the container. This system exception must be RuntimeException (or a subclass thereof). Check that your code is not throwing a checked exception, eg SQLException. If so, wrap it in EJBException and throw this exception.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Balazs Borbely
Ranch Hand

Joined: Oct 11, 2004
Posts: 33
There are two kind of exceptions specified in the EJB Specification.

1. Application exceptions: These are meant to be handled by the application(developer). So, when you catch the exception you may call setRollbackOnly() to rollback the transaction otherwise the transaction will be committed.

2. System exceptions: when a system exception is thrown than the transaction is rolled back.
Typically,this happens because the exception or error is unexpected, or the exception is expected but the EJB Provider does not know how to recover from it. Examples of such exceptions and errors are: failure to obtain a database connection, JNDI exceptions, unexpected RemoteException from invocation of other enterprise beans, unexpected RuntimeException, JVM errors, and so on.


'Make everything as simple as possible, but not simpler.' --Albert Einstein
Adrian Bates
Greenhorn

Joined: Jun 01, 2005
Posts: 24
Thanks for the replies guys.

So in my test case where I am forcing it to throw an application exception, DuplicateKeyException, I can catch this and throw an EJBException instead and this will cause a rollback? Is that right?

Adrian
Balazs Borbely
Ranch Hand

Joined: Oct 11, 2004
Posts: 33
Originally posted by Adrian Bates:

So in my test case where I am forcing it to throw an application exception, DuplicateKeyException, I can catch this and throw an EJBException instead and this will cause a rollback? Is that right?

Adrian


Yes, if your test case is in the transaction scope, I mean the transaction is not finished yet.

But I'd rather catch the exception sin the SessionBean's method and make explicitly the setRollbacOnly call than throw a RuntimeException. Throwing a RuntimeException is not a good practice.

Here you have a session bean mehod example with exception handling.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
Throwing a RuntimeException is not a good practice.

What is you reason for saying this?
Balazs Borbely
Ranch Hand

Joined: Oct 11, 2004
Posts: 33
Originally posted by Roger Chung-Wee:

What is you reason for saying this?


In my opinion all application exceptions (Business logic) exceptions should be checked exceptions.

Because, the client should be aware about the fact that the methods can throw an exception and be able to handle that exception.

In EJB if you throw a runtime exception the transaction will be rolled back, but maybe the business logic requires other handling...
For example:
In a method withdraw(500) if an InsufficientFundsException is thrown, you could withdraw as much as you can and go further. BUT if InsufficientFundsException
is unchecked the transaction is already set for rollback....

see the discution from: http://www.theserverside.com/news/thread.tss?thread_id=30911
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
In my opinion all application exceptions (Business logic) exceptions should be checked exceptions.

Because, the client should be aware about the fact that the methods can throw an exception and be able to handle that exception.

This is as per the EJB spec, so no argument here.

In EJB if you throw a runtime exception the transaction will be rolled back, but maybe the business logic requires other handling...
For example:
In a method withdraw(500) if an InsufficientFundsException is thrown, you could withdraw as much as you can and go further. BUT if InsufficientFundsException is unchecked the transaction is already set for rollback....

It would be poor design to make InsufficientFundsException a RuntimeException when the client can recover from this.

The most obvious reason to invoke setRollbackOnly() is when you do not wish the transaction to commit when an application exception is thrown. Most likely, it because an update has already been done in the transaction. So, if your code throws application exception DuplicateKeyException and you want to rollback, you handle the exception by invoking setRollbackOnly() and then rethrowing DuplicateKeyException. Your searchLang method is an example.

I would like to clarify this comment of mine.
Check that your code is not throwing a checked exception, eg SQLException. If so, wrap it in EJBException and throw this exception.

This is better rewritten as follows.
Check that your code is not throwing a checked exception which is not an application exception, eg SQLException. If so, wrap it in EJBException and throw this exception.

If you allow SQLException to propagate to the container, it will be thrown to the client - who will not know what to do with it. This is why checked exceptions (SQLException being a common example) which are unexpected should be encapsulated in EJBException and thrown.

Remember, an application exception is always a checked exception but a checked exception is not always an application exception.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Beginners question on EJB & transactions