Hi Justin,
On Sat, Sep 4, 2010 at 3:47 PM, Justin Sheehy <[email protected]> wrote: > Each instantiated riak_client has a unique client-id that will > represent that client in all updates (put-requests) that it makes. > That is, the entries in the vector clock will match that client-id. > Much of the value of vector clocks can vanish if concurrent writes to > the same values can be issued with the same client-id. > > Sharing connections as you describe might be fine, depending on the > details. However, if your resources might overlap in a way like the > following example then you probably have a problem. > > A and B are resource instances handling separate concurrent HTTP > requests but sharing a client-id C. > A issues get(K), receiving object X with vector clock V > B issues get(K), receiving object X with vector clock V > A issues put(K,Xa) where Xa is an update to X > B issues put(K,Xb) where Xb is an update to X > > You can lose one of the two updates, as they are both a single update > to V from client C. It is assumed that a given client will not > compete with itself for updates. What's the fun in that? ;-) > I hope that this explanation is helpful. Quite useful, thanks (once again). I haven't measured, but my intuition is that I don't want to create and shutdown a new riak pb client for each resource request (and the fact that there is no easy API for shutting down a pb client also leads me to think that this is not an intended use). Given that, it sounds like one would want a pool of pb clients such that each resource takes a client out of the pool when handling a request and returns it when done. So there would be no concurrent requests going through the same client. Does that seem like a reasonable approach? + seth -- Seth Falcon | @sfalcon | http://userprimary.net/ _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
