...
- We definitely want to guarantee that every distinct blob ever at a particular object ID will have a distinct version number, even across generations. (Ask Ryan for his lock example.)
- We probably also want to guarantee that version numbers for a particular object ID monotonically increase over time. This allows us to efficiently compare two version numbers and tell which one is more recent.
- We might also want to guarantee that the version number of an object increases by exactly one when it is updated. This allows clients to accurately predict the version numbers that they will write. (Ask Diego for his client-side transactions example.)
The current code guarantees (1) and (2) in the following way:
- There's a "master vector clock" named as safeVersion per master which contains the next available version number on that master. This is initialized to a small integer and is recoverable after crashes (see Recovery).
- When an object is created, its new version number is set to the value of safeVersion, and the safeVersion is incremented.
- When an object is deleted, if its version number is bigger than safeVersion, saveVersion is set to the version number plus one.
- Nothing happens to safeVersion at object update because as far as the object is alive the updated object refers the version number in the updating object.
--- Below is Obsolete .. --
The current code guarantees (1) and (2) in the following way:
- There's a "master vector clock" per table per master which contains the next available version number for that table on that master. This is initialized to a small integer when the table is created and is recoverable after crashes (see Recovery).
- When an object is created or updated, its new version number is set to the value of the master vector clock, and the master vector clock is incremented.
- Nothing special happens when an object is deleted.
...