please stop sending this crap !!!!
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 6:25 AM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] [ jboss-Feature Requests-430946 ] Reporting
> transaction failures
>
> 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_i
> d=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_i
> d=22866
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
