Hi Matt,
Like Sean said, you should have a mutator if you are dealing with
conflict resolution in domain objects; a good side effect of using a
mutator is that Riak Java client will fetch-modify-write so your
conflict resolver will be called once(?), if you don't use mutators, you
get the effect you are describing(?) or in other words, you have to
treat the operations as non-atomic and do things twice.
There are two interfaces for mutations: *Mutation* and
*ConditionalStoreMutation*, the 2nd interface will write only if the
object was actually mutated, you must return true or false to state if
it was mutated or not, which can be helpful if you are "mutating" an
object and you discover the change you are requesting to make was
already in place, then to save I/O, siblings creation and all implied on
a write operation you decide not to write back.
Mutation and conflict resolution are two separate concerns, but if you
specify a mutator and a conflict resolver, conflict resolution will
happen after the object is fetched and it is ready to be modified, which
will emulate an atomic operation if you use a domain object.
If you use a raw RiakObject, you must fetch, resolve the conflicts and
on the write operation pass the VClock which is not a trivial nor easy
to understand in code.
HTH,
Guido.
On 11/08/13 03:32, Sean Cribbs wrote:
I'm sure Roach will correct me if I'm off-base, but I believe the
store operation does a fetch and resolve before writing. I think the
ideal way to do that is to create a Mutation<T> (T being your POJO) as
well, in which case it's less of a "store" and more of a
"fetch-modify-write". The way to skip the fetch/modify is to use the
withoutFetch() option on the operation builder.
On Sat, Aug 10, 2013 at 6:50 PM, Matt Painter <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I've just rolled up my sleeves and have started to make my
application more robust with conflict resolution.
I am currently using a @RiakVClock in my POJO (I need to think
more about whether the read/modify/write approach is preferable or
whether I'd have to rearchitect things).
I read in the Riak Handbook the recommendation that conflicts are
best resolved on read - not write - however the example App.java
snipping on the Storing data in Riak
<https://github.com/basho/riak-java-client/wiki/Storing-data-in-riak#appjava>
page
in the Java client's doco uses a resolver on both the store() and
fetch() operations.
Indeed, if I don't specify my conflict resolver in my store(),
things blow up (in my unit test, mind - I'm still getting my head
around the whole area so my test may be a bit contrived).
However when I use it in both places, my conflicts are being
resolved twice. Is this anticipated?
My store is:
bucket.store(record).returnBody(true).withoutFetch().withResolver(myConflictResolver);
and my fetch is:
bucket.fetch(id,Record.class).withResolver(myConflictResolver).execute();
The order of operations in my test is:
1. Store new record
2. Fetch the record as firstRecord
3. Fetch the record as secondRecord
4. Modify a field on firstRecord and secondRecord
5. Save firstRecord
6. Save secondRecord- this invokes my resolver with two siblings
7. Read record - this also invokes my resolver with the two siblings
Am I missing something? Or is this what's supposed to happen? I'm
not too worried - the double-handling is hardly that intensive -
but I'm keen to get it right.
Thanks in advance,
Matt
_______________________________________________
riak-users mailing list
[email protected] <mailto:[email protected]>
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
--
Sean Cribbs <[email protected] <mailto:[email protected]>>
Software Engineer
Basho Technologies, Inc.
http://basho.com/
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
