From: Jim Starkey
Date: January 28 2009 7:49pm
Subject: Re: Problems with record visibility and how it is computed
List-Archive: http://lists.mysql.com/falcon/441
Message-Id: <4980B6CD.7080907@nimbusdb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ann W. Harrison wrote:
>
>>
>>> Suppose we had a reusable transaction id as an index into a 
>>> transaction state vector.  That would tie down only a byte per 
>>> transaction rather than a large object.  We would still need a 
>>> mechanism to recycle the transaction ids, however.  Something might 
>>> take a day and think about this...
>>
>> Sounds as big a change as cycle locking.  Let's talk about wait 
>> states with a cycle lock first...
>
>
> I'm not sure that the state vector is that large a change - maybe
> because I've worked with vectors of transaction states before.
>
> It needs to be bigger than a byte - it needs to be the same size
> as the commit id because it has to hold the commit id.  And it
> ought to be a sparse vector - no point in wasting space on
> read-only transactions.  And changing the state of an entry
> has to be done carefully to make the effect atomic. And there
> has to be some way to release the top of the list when nobody
> cares about it any more...
Don't assign the id until the transaction actually does an update.
>
> But it has the advantage of working ... of course making it
> sparse does complicate everything and gets back into locking...
>
>
We could probably make a sparse array that was updated exclusively with 
interlocked CAS -- something to think about when the dog and a fox get 
into a middle of the night bark-fest.


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