>
>> 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...
But it has the advantage of working ... of course making it
sparse does complicate everything and gets back into locking...
Regards,
Ann
