Java broadly divides exceptions into two types: checked and unchecked. Unchecked exceptions derive from RuntimeException or Error. Everything else is a checked exception. Checked exceptions are the ones that the compiler forces you to either catch or else declare with a throws clause in your method declaration.
The EJB spec talks about application and system exceptions. Broadly, EJB system exceptions are the same as Java unchecked exceptions, with the addition of anything deriving from java.rmi.RemoteException. That is, EJB system exceptions are RuntimeException, Error and RemoteException and their descendants. RuntimeException and Error should never be generated by your code - they typically come from the JVM in response to critical, non-recoverable system problems (like, out of memory, etc.) RemoteException should also never be generated by your code - they are generated by the RMI runtime in response to comms (network) related problems. Since you should never be generating any of these EJB system exceptions, (and most of them are unchecked anyway) it is unreasonable for the container to expect you to deal with them. Therefore, if any of these make their way out of your bean method, the container will catch them and roll back your transaction for you. However, any EJB application exceptions (everything other than system exceptions) are checked. Therefore, the compiler will force you to catch them or explicitly rethrow them. Since you are forced into doing this, the container assumes that you have the power to decide whether to roll back the transaction or not. If you propogate these exceptions back up to the container, it will send them across the wire and they will appear on your client. This is good. However, the container doesn't know if the client is capable of retrying the operation, etc. Therefore it doesn't automatically roll back the transaction. So... the compiler is your friend. If you always catch the exceptions it tells you to catch, then you will be in command of all EJB application exceptions. You can then decide what the correct action is. In my experience, the correct action is typically to roll back the transaction and then rethrow the exception so that the client is aware of it. For a more thorough treatment of this subject, check out Monson-Haefel, Enterprise Java Beans (I have the 3rd edition which covers EJB2.0) published by O'Reilly. Chapter 14 deals with transactions, and the section 'Exceptions and Transactions' deals with exactly that, and very thoroughly. I highly recommend the table on pp439-441 (of the 3rd edition). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3838969#3838969 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3838969 ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
