I agree with you Armin....it would be better to not throw an Exception if abort()
is called multiple times.
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, <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
