Re: New Transaction State object (Was: Problems with record visibility and how it is computed)

[Jim Starkey]

Olav Sandstaa wrote:
>> The question is how one transaction waits for another.  Does this 
>> work (or is there a simpler way):
>>
>>   1. Get a shared lock on active transaction list
>>   2. Call addRef on transaction to wait for
>>   3. Release shared lock on active transaction list
>>   4. Wait on other transaction syncPending
>>   5. Release syncPending
>>   6. Call release on transaction waited on
>
> This is about how Transaction::waitForTransaction() is implemented 
> today. But I think there is one step missing (and that is also the 
> cause for one of the crashes seen a few times: bug#41665). (in 
> addition step 1 and 2 in the current implementation is in reverse 
> order - which is not good either).
>
> The problem with the above is step 2 (I think): Even if you get a 
> shared lock on the active transaction list there is no guarantee that 
> the transaction still is in the active transaction list when you call 
> addRef() on it (and might be deleted). To get around this, I see two 
> ways:
>
> 1b: search for the transaction in the active list - if found, then 
> continue, if not found then assume it is committed (and return) (and 
> NO I do not like searching the list)
> 1b: check the transaction state object: if this still says that the 
> state of the transaction is "Active or Limbo" then you can do the 
> addRef() on the transaction object.
>
> (but in the working version I have right now the 
> syncIsActive/syncPending object is moved to the Transaction State 
> object and we do not have this issue - (just a "fat" transaction state 
> object :-( )
>
>
Olav, I think it's simpler than that.  After getting the lock on the 
active transaction list, check the transaction's state.  If it's Active 
or Prepared, you're safe because the transaction gets an exclusive lock 
on the active transaction list before change the transaction state.  If 
it's Committed or RolledBack, no wait is required.



-- 
Jim Starkey
President, NimbusDB, Inc.
978 526-1376