Question about Transaction timeouts and Journal

[clebert.suconic]

What should happen if Journal::appendCommitRecord is called, but the transaction times out on AIO:write. (for any circunstance such as high load on the system and short configured timeouts).

What would be the expected behavior after such failure?

Rollback should be called after that?

Any scenarios where the commit would be retried? (XA maybe?)

I'm asking that because at the moment, after a failing commit it won't be possible to retry or rollback the transaction if a timeout happened during the writeTransaction.

[timfox]

it won't be possible to retry or rollback the transaction if a timeout happened during the writeTransaction.

Why?

[clebert.suconic]

"timfox" wrote:

it won't be possible to retry or rollback the transaction if a timeout happened during the writeTransaction.

Why?

http://anonsvn.jboss.org/repos/messaging/trunk/src/main/org/jboss/messaging/core/journal/impl/JournalImpl.java

 public void appendCommitRecord(final long txID) throws Exception
 {
 if (state != STATE_LOADED)
 {
 throw new IllegalStateException("Journal must be loaded first");
 }

 JournalTransaction tx = transactionInfos.remove(txID);

 if (tx == null)
 {
 throw new IllegalStateException("Cannot find tx with id " + txID);
 }

 JournalFile usedFile = writeTransaction(COMMIT_RECORD, txID, tx);

 transactionCallbacks.remove(txID);

 tx.commit(usedFile);

 }

transactionsInfo is removed before writeTransaction is completed.

If the transaction times out, during a retry... you would get the exception thrown by "cannot find tx with id " + txID, and doesn't seem the right behavior to me.

I'm writing a testcase where that is failing.

[timfox]

Standard local transactions, will never have commit retried, they should always clear up their state on failure of commit (effectively rollback).

For XA transaction branches however, the tx mgr may decide to retry the commit before the server is restarted so we need to support that.

[clebert.suconic]

The problem with a timeout during the Commit is, I have no guarantees if the Commit will make to the file or not.

As libaio don't have an abort method (Actually it does.. but its implementation is empty.. it's just a stub for future versions), on that situation you might have a Rollback arriving after the Commit. If you reload the Journal at that point you might get duplicates.

So.. what I'm doing is treating that as an unlikely exception.

So.. what I'm doing is.. if a Rollback arrives after a Commit, I will ignore that load, and restart the load but ignoring this exceptional situation.

A timeout during commit will be an unlikely event but I would prefer to have the exception code for that

[clebert.suconic]

The problem with a timeout during the Commit is, I have no guarantees if the Commit will make to the file or not.

I mean... I could still have the Commit Record on the file, even thought the write timed out. Say.. it timed out at 3 seconds... but it could complete after 5 seconds.

As I already said.. this is unlikely to happen.. but if it does it would duplicate messages if we didn't have the code to treat that.

[clebert.suconic]

As we discussed on #jbossmessaging@freenode, I will just block until the transaction is completed... the same way it would happen with a regular sync / NIO.