List:Falcon Storage Engine« Previous MessageNext Message »
From:Jim Starkey Date:March 20 2009 2:42pm
Subject:Re: New Transaction State object (Was: Problems with record visibility
and how it is computed)
View as plain text  
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

Thread
Problems with record visibility and how it is computedOlav Sandstaa21 Jan
  • search for null values in indexed columnsVladislav Vaintroub21 Jan
    • Re: search for null values in indexed columnsLars-Erik Bjørk21 Jan
    • Re: search for null values in indexed columnsKevin Lewis21 Jan
      • RE: search for null values in indexed columnsVladislav Vaintroub21 Jan
        • Re: search for null values in indexed columnsKevin Lewis21 Jan
      • Re: search for null values in indexed columnsJames Day23 Jan
  • Re: Problems with record visibility and how it is computedOlav Sandstaa23 Jan
    • Re: Problems with record visibility and how it is computedJim Starkey23 Jan
      • Re: Problems with record visibility and how it is computedKevin Lewis28 Jan
        • Re: Problems with record visibility and how it is computedJim Starkey28 Jan
          • Re: Problems with record visibility and how it is computedKevin Lewis28 Jan
            • Cycle Locking (was Problems with record visibility and how it iscomputed)Jim Starkey28 Jan
            • Re: Problems with record visibility and how it is computedAnn W. Harrison28 Jan
              • Re: Problems with record visibility and how it is computedJim Starkey28 Jan
                • Re: Problems with record visibility and how it is computedAnn W. Harrison28 Jan
                  • Re: Problems with record visibility and how it is computedOlav Sandstaa26 Feb
                    • New Transaction State object (Was: Problems with record visibility andhow it is computed)Olav Sandstaa16 Mar
                      • Re: New Transaction State object (Was: Problems with record visibilityand how it is computed)Kevin Lewis16 Mar
                      • Re: New Transaction State object (Was: Problems with record visibilityand how it is computed)Jim Starkey16 Mar
                        • Re: New Transaction State object (Was: Problems with record visibilityand how it is computed)Olav Sandstaa19 Mar
                          • Re: New Transaction State object (Was: Problems with record visibilityand how it is computed)Jim Starkey19 Mar
                            • RE: New Transaction State object (Was: Problems with record visibilityand how it is computed)Vladislav Vaintroub20 Mar
                            • Re: New Transaction State object (Was: Problems with record visibilityand how it is computed)Olav Sandstaa20 Mar
                              • Re: New Transaction State object (Was: Problems with record visibilityand how it is computed)Jim Starkey20 Mar
          • Re: Problems with record visibility and how it is computedOlav Sandstaa28 Jan
            • Re: Problems with record visibility and how it is computedJim Starkey28 Jan
              • Another Idea for Transaction Lifetime ControlJim Starkey28 Jan
                • Re: Another Idea for Transaction Lifetime ControlJim Starkey29 Jan
              • RE: Problems with record visibility and how it is computedXuekun Hu4 Feb
          • Re: Problems with record visibility and how it is computedAnn W. Harrison28 Jan
  • Quick question on row countsKeith Murphy24 Jan
    • Re: Quick question on row countsJim Starkey25 Jan
      • Re: Quick question on row countsKeith Murphy25 Jan