Bug in TransactionImpl?

[Da...@Equifax.com]

I believe that I have found a bug in TransactionImpl. But I could be wrong, and
if I am, would be interested in hearing why.

Some background: We are using RC4. We wrap the OJB transaction in an application
Transaction that performs some additional processing for us.  Our service layer
begins a Transaction, does some processing, and commits the Transaction (which
commits the underlying TransactionImpl). If an Exception occurs, the service
layer call abort on our Transaction object (which calls abort on the
TransactionImpl). This all works fine when there is an Exception in the service
layer processing. However, there is a problem rollingback if there is a problem
in the TransactionImpl#commit.

Code for our Transaction#abort looks something like this

            if (tx != null && tx.isOpen())
            {    tx.abort();   }

along with some other processing. But if OJB has rolledback the transaction, this
test will pass, but the tx.abort() will throw an Exception.


The problem here is that in TransactionImpl#commit(), if an Exception occurs, the
status is set to STATUS_MARKED_ROLLBACK, and doAbort() is called. I believe that
abort() should be called instead. Calling abort() would result in the status
being set to STATUS_ROLLEDBACK, which would cause the tx.isOpen() test to fail.
In addition, PersistenceBroker#abortTransaction() would be called, which would
trigger the aborted transaction Listener events.

Is there a reason for calling doAbort() rather tha abort() that I am missing?

Dave Derry



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: Bug in TransactionImpl?

[Armin Waibel <ar...@code-au-lait.de>]

Hi,

I think you are right.

> Is there a reason for calling doAbort() rather tha abort() that I am 
> missing?
I don't know the reason. I add some new tests, seems that invoke
'abort()' instead 'doAbort()' does work.

Only problem:
> Code for our Transaction#abort looks something like this
>
>             if (tx != null && tx.isOpen())
>             {    tx.abort();   }
>
If someone does not check tx.isOpen() I think the 'abort()' call
shouldn't throw an exception, thus we have to ignore multiple
'abort()' calls if an tx is already rolledback and add on abort
method

if(m_txStatus == Status.STATUS_ROLLEDBACK)
{
    return;
}

What do you think?

regards,
Armin



On Tue, 14 Oct 2003 12:02:25 -0400, <Da...@Equifax.com> wrote:

> I believe that I have found a bug in TransactionImpl. But I could be 
> wrong, and
> if I am, would be interested in hearing why.
>
> Some background: We are using RC4. We wrap the OJB transaction in an 
> application
> Transaction that performs some additional processing for us.  Our 
> service layer
> begins a Transaction, does some processing, and commits the Transaction 
> (which
> commits the underlying TransactionImpl). If an Exception occurs, the 
> service
> layer call abort on our Transaction object (which calls abort on the
> TransactionImpl). This all works fine when there is an Exception in the 
> service
> layer processing. However, there is a problem rollingback if there is a 
> problem
> in the TransactionImpl#commit.
>
> Code for our Transaction#abort looks something like this
>
>             if (tx != null && tx.isOpen())
>             {    tx.abort();   }
>
> along with some other processing. But if OJB has rolledback the 
> transaction, this
> test will pass, but the tx.abort() will throw an Exception.
>
>
> The problem here is that in TransactionImpl#commit(), if an Exception 
> occurs, the
> status is set to STATUS_MARKED_ROLLBACK, and doAbort() is called. I 
> believe that
> abort() should be called instead. Calling abort() would result in the 
> status
> being set to STATUS_ROLLEDBACK, which would cause the tx.isOpen() test 
> to fail.
> In addition, PersistenceBroker#abortTransaction() would be called, which 
> would
> trigger the aborted transaction Listener events.
>
> Is there a reason for calling doAbort() rather tha abort() that I am 
> missing?
>
> Dave Derry
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org