>From the Spec (11.3.4.2)
"An enterprise bean with container-managed transaction demarcation can use
the setRollbackOnly() method of its EJBContext object to mark the
transaction such that the transaction can never commit. Typically, an
enterprise bean marks a transaction for rollback to protect data integrity
before throwing an application exception, because application exceptions do
not automatically cause the Container to rollback the transaction."
Key point to note here is that an exception does *not* indicate a rollback
condition.
jim
----- Original Message -----
From: Sam <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 05, 2000 3:39 PM
Subject: Re: Exceptions and Transactions
> Ok, That was my mistake.Let me explain this clearly.
> My question was simply, if a method does not throw an exception and
> swallows it,
> is the transaction for that method rolled back ?
>
> The answer that I have found to that is no. Unless the method throws an
> exception
> there is no way for the transaction to be rolled back.
>
>
> try{
> method1();
> }catch(MethodOneExceptoin e){
> file://do something here
> }
> method2(); // call only if there is no exception
> }
>
> YES I agree that simply,moving the call to method2() within the try
> catch block will do that for me,
> but I wanted tosee the transaction rollbacks work.
> And No, it wont work like that but this will.
>
> public void xxx throws MethodOneException(){
> method1();
> method2();
> }
>
>
> So back to my basic question. If the method needs to be transaction safe
> , it should not swallow exceptoins.
> If it does, it should try recovering from them.
>
> Also is it worth noting that in the following block any work done by the
> call to method2() will not be rolled back due to the exception
>
> public void method1(){
> method2();
> try{
> >>>>> Some sql code
> }catch(Exception e){}
> }
>
>
>
> -Sam
>
>
>
> [EMAIL PROTECTED] wrote:
> >
> > On 01/05/2000 at 10:46:42 AM, Sameer Tyagi <[EMAIL PROTECTED]> wrote:
> > public void method1(){
> > try{
> > >>>>> Some sql code...
> > }catch(SQLExceptoin e){
> > file://do something here
> > }
> > method2();
> > }
> >
> > To preserve integrity,method2 must be executed when the preceeding sql
> > code is sucessfully executed.
> >
> > How can this be done with transactions WITHOUT doing a return in the
> > catch block ???
> >
> > Um... How about something simple? Is there something that is preventing
you
> > from doing this?
> >
> > public void method1() {
> > success = false;
> > try{
> > >>>>> Some sql code...
> > success = true;
> > } catch(SQLException e){
> > file://do something here
> > }
> > if (success) {
> > method2();
> > }
> > }
>
>
===========================================================================
> 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".
