Objects in RAMCloud have version numbers to support atomic operations.
Note that only the latest version of an object is ever used — RAMCloud does not store all previous versions of an object.
- 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" 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.
A slightly different implementation could guarantee (1), (2), and (3):
- Keep the master vector clock, initialize and recover it the same.
- When an object is created, its new version number is set to the value of the master vector clock, and the master vector clock is incremented.
- When an object is updated, its new version number is set the old blob's version number plus one.
- When an object is deleted, set the master vector clock to max(master vector clock, the deleted blob's version number plus one).
As of 2010-02-09, we have not decided whether we want to guarantee (3).