> The lock that prevents action being taken on a record being committed by
> transaction A is Transaction::syncIsActive.
> Transaction::waitForTransaction() gets a shared lock on it if
> Transaction::state == active. So now we have this order
> 1) synchronously move trans from Active to committed lists
> 2) Transaction::state = committed
> 3) Durability - write committed record to serial log.
> 4) Transaction::syncIsActive.unlock()
> There is admittedly a gap between 2 and 4 where another transaction can
> take action on a record that is "committed" but not yet durable.
And I worry that a transaction could start, read the committing
transaction's work, and commit in that gap. Seems unlikely, but
really mystic things happen between instructions under load.
> > 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.
> Good idea. The gopher thread can get a quick shared lock on
> Transaction::syncIsActive before processing it. Since the gopher is in
> the background the performance cost is acceptable. And the transaction
> in the serial log with writePending == true has a predictable path
> bewteen Transactin::state == active to committed. So that wait is
> I'll try it.
> It is still a good idea to do #3-durability before #4-signal, right?
> It was the other way around.
Oh yes, absolutely! Regardless of what state the transaction may
claim or what list it's on, the actual commit happens when the
serial log commit record hits oxide (or SSD). If we can keep an
over active gopher from getting confused, I'd like to see the
1) Durability - write committed record to serial log.
2) synchronously move trans from Active to committed lists
3) Transaction::state = committed
Nothing is lost if a new transaction sees a transaction that is
in the process of committing as uncommitted - if it had started
a microsecond sooner, the transaction would have been active.
Not seeing concurrent results (except in special cases of unique
and foreign key constraints) is not a problem. Seeing results
that are not actually durable is a major violation of transaction