Wrapping my thinking around vector clocks
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? Thanks JK Note that I need a general solutioso any -- It's always darkest just before you are eaten by a grue. ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Trouble running under OpenSolaris
I downloaded the latest pre-built riak for OpenSolaris and installed it on the latest OpenSolaris release. When I run bin/riak start I get the following errors: riak@opensolaris:~$ bin/riak start WARNING: ulimit -n is 256; 1024 is the recommended minimum. bin/riak: line 71: /opt/riak/erts-5.7.5/bin/escript: cannot execute binary file bin/riak: line 79: /opt/riak/erts-5.7.5/bin/run_erl: cannot execute binary file ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Two question in re pre/post commit hooks
(1) AIUI a given key/value data pair is "owned" by a given node at one time and operations on it happen on that node and are then replicated out. Is this correct? (2) Is the key/value pair "locked" between pre update and post update? The motivation for this question is this. I need to do the following operations on update: (1) In the pre-update hook, get the existing value (lets call it A) (2) Compare some data in the update (lets call it A') with A (3) Validate or reject the update based on that comparison (4) If validated, write A' out as the new value of A, if not, return a validation error. I need 1-4 to happen in a consistent fashion, If someone else can come in and update A after (1) but before (4), the scheme wont work. I *could* do my own locking in (1) and then add an unlock step in (5) assuming that all updates will take place on the same node, but I dislike injecting locking into a system that has unknown other expectations of the operation. -- It's always darkest just before you are eaten by a grue. ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Two questions about pre/post update hooks
(1) AIUI a given key/value data pair is "owned" by a given node at one time and operations on it happen on that node and are then replicated out. Is this correct? (2) Is the key/value pair "locked" between pre update and post update? The motivation for this question is this. I need to do the following operations on update: (1) In the pre-update hook, get the existing value (lets call it A) (2) Compare some data in the update (lets call it A') with A (3) Validate or reject the update based on that comparison (4) If validated, write A' out as the new value of A, if not, return a validation error. I need 1-4 to happen in a consistent fashion, If someone else can come in and update A after (1) but before (4), the scheme wont work. I *could* do my own locking in (1) and then add an unlock step in (5) assuming that all updates will take place on the same node, but I dislike injecting locking into a system that has unknown other expectations of the operation. -- It's always darkest just before you are eaten by a grue. ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: Locking
jon gave a much better and more detailed description, but fundamentally no true lock is possible without an atomic test and set operation. So far, of all the No Sql DBs I've looked at, only Mongo has that capability. On Sun, Jul 31, 2011 at 4:55 PM, Soren Hansen wrote: > I've seen a couple of posts here and there on the subject of a locking > mechanism for Riak, most notably: > > http://riak-users.197444.n3.nabble.com/Riak-and-Locks-td1866960.html > > While it would only serve as an advisory locking mechanism, wouldn't a > bucket with a reasonably high n, w and dw set equal to n, a > deterministic naming scheme for the object being locked, and a locking > algorithm such as: > > 1. PUT /locks/object_id > If-None-Match: * > Body: > > 1a. If this fails, wait for a while, then try again. > 1b. If it succeeds, proceed to 2. > > 2. The doc for If-None-Match says "this does not prevent concurrent > writes; it is possible for the condition to evaluate to true for > multiple requests if the requests occur at the same time." I'm not > completely sure if n=w=dw protects me from concurrent writes (I'm not > familiar with the locking semantics of a single riak instance). > Anyway, if I'm in fact not protected, the next step is to read the > value back to make sure we're actually the ones holding the key. If > not, go back to step 1. If yes, proceed as planned. > > 3. Once you're done with the lock, just DELETE it. > > If this were really that simple, someone would have suggested it. So, > what is this Riak rookie (i.e. I) missing? > > > -- > Soren Hansen| http://linux2go.dk/ > Ubuntu Developer| http://www.ubuntu.com/ > OpenStack Developer | http://www.openstack.org/ > > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
