After I sent this email, Richard Monson-Haefel pointed out that my reply misses the case when the bean marks the transaction for rollback before it throws the application exception. In this case, if the bean didn't run in the client's transaction context, the container would rollback the transaction and re-throw the application exception to the client. Even including this case, the client recovery strategy is the same. When a client gets an application exception, the client can continue computation and recover the exception. A refinement is that the client first checks the transaction status before it continues computation. In the above case, the client's transaction would not be marked for rollback. Vlada ----- Original Message ----- From: Vlada Matena <vlada@eng> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, December 14, 1999 9:24 AM Subject: Re: EJB 1.1: AppExceptions and Tx > > ----- Original Message ----- > From: Richard Monson-Haefel <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, December 14, 1999 7:54 AM > Subject: EJB 1.1: AppExceptions and Tx > > > > EJB 1.1 Exception Handling section its specifies that that an > > application exception thrown from a container initiated transaction (one > > that starts with the bean invocation) may or may not indicate a > > transaction rollback. This seems flawed to me. The bean should be > > required to throw a system exception (possibly wrapping a application > > exception) if a transaction roll back is forced > > (EJBContext.rollbackOnly()). Also the container should throw a > > RemoteExcepton if the bean explicitly rolls back the transaction or if > > the container fails to commit the transaction after receiving an App > > Exception. > > > > As it stands now, an application exception thrown by a bean that started > > its own transaction (Required, Required New) may or may not indicate > > that the transaction was rolled back. Since there is no way to check on > > the success of the transaction from the bean's client, their is no way > > If the client gets an application exception, it knows that the bean's transaction > was not rolled back at the end of the method. If the client runs in the same > transaction as the bean that threw the exception, the client's transaction > might have been marked for rollback by the bean. The client can find out > by inquiring about the transaction status. > > > to recover or even to know if a recovery is necessary. IMO this is a > > serious flaw in the exception handling model introduced in EJB 1.1 > > (otherwise the new model is excellent). > > > > I'm looking for a Sun Authority to comment. > > > > Thanks, > > > > Richard > > > > -- > > Richard Monson-Haefel > > EJB Expert for jGuru.com > > ( http://www.jguru.com ) > > > > Author of Enterprise JavaBeans > > Published by O'Reilly & Associates > > ( http://www.ejbnow.com ) > > > > =========================================================================== > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > > of the message "signoff EJB-INTEREST". For general help, send email to > > [EMAIL PROTECTED] and include in the body of the message "help". > > > > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
