Jim,
Talking about keeping the size of a vector of transaction
commitId's indexed by the transactionId reasonably dense...
> Don't assign the id until the transaction actually does an update.
OK, so the Transaction object has four identifiers .... first, its
address, second its startId, third its updateId, and fourth its
commitId. The address is in general use, the startId determines
what it sees, the updateId is written into its record versions,
and its commitId determines who can see its changes... did I
get that right?
>
> 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.
Yes, I was thinking along those lines ... and that "vector" changes
on transaction commit - thus once per updating transaction, not once
per record or once per record view...
Cheers,
Ann
