[JBoss-dev] [ jboss-Feature Requests-430946 ] Reporting transaction failures

[<no...@so...>]

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