Wrapping my thinking around vector clocks

Jeffrey Kesselman jeffpk at gmail.com
Thu Apr 21 14:47:49 EDT 2011

Hi Guys,

I've been studying Riak and am considering a major technology base
shift in a project I've been working on for more then  a decade (the
Project Darkstar/RedDwarf game server.)  As may coming to this from a
strict RDBMS background I am sure, I am trying to wrap my head around
vector clocks.

I read the "Why vector clocks are reasy" blog and think i follow that.
 My question is this: what if I have multiple data changes to multipel
data structures that all have to remain in sync (be atomic)? Which
data strictures are  involved in any one change is not predictable.  I
can allow for eventual resolution of that consistent state, and even
change from one consistent state to another, but the state must always
be consistant.  This is easy to do in a traitional transaction btu im
having trouble with the VC equivalent.

As a gedanken experiment picture two players trying to buy a limited
commodity of which there is only 1 available.  In both cases they are
attempting to decrement their money, remove the object from the store
inventory, and add it to their own inventory. Only one can succeed as
these 3 actions must be atomic.  It is okay for both to initially
think they succeeded as long as next time we go to look at these
states they resolve themselves. (Assume a resolution mechanism, for
argument we can say earliest timestamp wins.)

This needs to be a general solution, knowledge of what the data
structures are or do *cannot* be part of the solution.  This means
that the item cant itself have an "owner" field which is part of the
disambiguating logic.  Disambiguating all structures (the 2 player
inventories, the store  inventory and the two players money values)
must be done without any semantic knowledge of what the data is for.

Is this possible?  Can someone lay out the solution based on the
simpel case above?



Note that I need a general solutioso any

It's always darkest just before you are eaten by a grue.

More information about the riak-users mailing list