List:Falcon Storage Engine« Previous MessageNext Message »
From:Ann W. Harrison Date:December 3 2008 5:22pm
Subject:Re: Bug 41194
View as plain text  

> 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 
> deterministic.
> 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
order as:

  1) Durability - write committed record to serial log.
  2) synchronously move trans from Active to committed lists
  3) Transaction::state = committed
  4) Transaction::syncIsActive.unlock()

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



Bug 41194Ann W. Harrison3 Dec
  • Re: Bug 41194Kevin Lewis3 Dec
    • Re: Bug 41194Ann W. Harrison3 Dec
      • RE: Bug 41194Xuekun Hu4 Dec
  • Re: Bug 41194Kevin Lewis4 Dec
    • RE: Bug 41194Xuekun Hu4 Dec
  • Re: Bug 41194Ann W. Harrison4 Dec
    • RE: Bug 41194Xuekun Hu5 Dec
  • Re: Bug 41194Kevin Lewis4 Dec
  • Re: Bug 41194Kevin Lewis5 Dec
    • RE: Bug 41194Xuekun Hu5 Dec