-
1. Re: Question about Transaction timeouts and Journal
timfox Jul 23, 2008 11:31 PM (in response to clebert.suconic)"clebert.suconic@jboss.com" wrote:
it won't be possible to retry or rollback the transaction if a timeout happened during the writeTransaction.
Why? -
2. Re: Question about Transaction timeouts and Journal
clebert.suconic Jul 24, 2008 12:56 AM (in response to clebert.suconic)"timfox" wrote:
"clebert.suconic@jboss.com" 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.javapublic 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. -
3. Re: Question about Transaction timeouts and Journal
timfox Jul 24, 2008 6:01 AM (in response to clebert.suconic)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. -
4. Re: Question about Transaction timeouts and Journal
clebert.suconic Jul 24, 2008 8:23 AM (in response to 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 -
5. Re: Question about Transaction timeouts and Journal
clebert.suconic Jul 24, 2008 8:25 AM (in response to 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. -
6. Re: Question about Transaction timeouts and Journal
clebert.suconic Jul 24, 2008 10:30 AM (in response to 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.