Jeffrey, 1.) a given key/value data pair is owned by multiple nodes, depending on your replication level. Operations on a particular key/value pair happen on all nodes that are primary replicas, but requests leading to these operations can be coordinated by any node in the cluster. So when you write a piece of data, N nodes will be involved in the process. But your commit hooks will only be run on the coordinating node, the one you sent the request to. Ownership can change at any time when nodes go down or the cluster changes due to new nodes entering oder old nodes leaving.
2.) The key/value pair is not locked. As per above, this would require a distributed lock across all replicas of the key/value pair, which is not how Riak works. While the update itself is coordinated by a single process on the coordinating, at any time, a different client could come along and update the same piece of data through a different path, so e.g. through a different or even the same node. The original updater doesn't have any knowledge of that, if it's a conflicting update, it will simply create a sibling (given you enabled sibling creations on that particular buckets). You may want to look into Statebox [1] as an alternative way, or try to serialize writes through a messaging system like RabbitMQ to ensure atomicity to a certain extent. [1] https://github.com/mochi/statebox Mathias Meyer Developer Advocate, Basho Technologies On Freitag, 8. Juli 2011 at 19:14, Jeffrey Kesselman wrote: > (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 (mailto: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
