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
