Hi Brian, */New thread for this, sorry for the hijacking./*
Yes, without fetch should be indeed used without mutation or conflict resolution, originally we had mutations and siblings, but our application ended up creating too many siblings and made Riak fail miserably, so we disable the siblings and left the mutation in place cause it is nice for separation of concerns and a good idiom for fetch-modify-write.
We have two types of objects, the ones that are created and never modified and others which contain historical data, and we use Riak because the AP part of the CAP theorem but we have to deliver consistent data so we have a sort of DAO pattern which fetch from cache if present or Riak, then locks using a well written in-memory locking mechanism, applies mutation to cached object.
For performance reasons and let me say this, for single reader/writer it provides a very high performance cause we read and/or write optionally using withoutFetch() and/or ConditionalStoreMutation<T>
All that said, "the little sense of withoutFetch() and mutation" got some value for us, I guess it is a mutation side effect, having all the logic to verify that an object has changed or not, locking mechanism and caching would be too difficult and confusing without the current Riak Java client mutation mechanism, we have been using it for over a year now and we haven't seen any weirdness in it, not even once, I mean the weirdness related with concurrent applications.
Hope with this long explanation (sorry about that) you now connect the pieces of our pull requests,
Let me know your thoughts, Guido.
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
