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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
