Feature Requests item #430946, was updated on 2001-06-06 22:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=430946&group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Marco Hunsicker (marcohu) Assigned to: Nobody/Anonymous (nobody) Summary: Reporting transaction failures Initial Comment: I have a 'feature request' regarding the transaction implementation of the beloved JBoss. I'm currently testing an EJB entity bean and detected the following issue: In the case where a user tries setting invalid data and this data is about to be synchronized with the database, my bean throws a java.lang.IllegalArgumentException with a detailed (and useful!) exception message. This exception is caught in ejbStore(), encapsulated with an EJB Exception and rethrown as to explain my implementation of the bean. The JBoss log file exposes this behaviour as the EJBException shows up there. I expected the pending transaction to be rolled back and my thrown EJBException travelling through the proxy to the client to indicate the error. Indeed, the transaction is unable to commit, but instead of the root cause, the client gets an javax.transaction.RolledbackException with no explanation of the error. Hm, the RollbackException makes sense to me, as the database rejected the change. But it would be much better if the exception could be holding information about the reason why the transaction failed. The JDK javadocs states that javax.transaction.RollbackExcetion is a 'local' exception. So if we want to pass a transaction exception back to the client it maybe would be better to throw a javax.transaction.TransactionRolledbackExeption instead (having the 'detail' field to store the cause). Clients would then be able to resolve the root cause. Skimming through TxCapsule.java (where the RollbackException originates, I'm refering the JBoss 2.2.2 release source), I've learned that every transaction has its own context. Therefore, what about adding a member field for the exception causing a status change? Then we would be able to throw a javax.transaction.TranscationRolledbackException which holds the root cause in its 'detail' field. This of course, would mean changes to all the dependend classes as well. Maybe these will be possible in an upcoming release... Cheers, M.H. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=430946&group_id=22866 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
