Kevin,
I'm concerned about your second fix to bug 41194.
"The previous patch [which delayed switching the transaction
state to committed] does not work. What happens is that the
gopher thread immediately starts processing the serial log
commit record and gets all the way to Transaction::writeComplete
before the Transaction::commit even gets to the state = committed;
line. So then it asserts in writeComplete that (state == committed).
"The call to database->commit(this); does not have to occur before
switching the transaction from activeTransaction list to
comittedTransactions. But it does need to be called before other
waiting transactions are signaled that this transaction is
committed."
Obviously, the assertion you saw in the gopher thread is a problem,
but I worry that your solution introduces another possible failure
that will be harder to detect. Consider a transaction A that's
starting to commit. It moves itself to the committed list.
Transaction B starts. B has never waited for A, but reads a
record that A created and takes some action based on that record,
and commits itself. Then A's call to database->commit(this) fails.
Unless there's a lock that I haven't seen that keeps B from
starting or committing while A is between moving itself to the
committed list and actually writing its commit to the serial
log, there's a problem.
An alternate solution might be to have the gopher check that
the transaction either no longer exists or has a state of
committed before it starts to move changes out of the serial
log.
Cheers,
Ann
