One easy way to solve an atomic a->b relationship in an eventually
consistent way is to require the existence of both A and B in order to
consider the write valid, to write A first, and use a message queue to
retry writes until both A and B exist. There are other approaches for
agreement between objects, but they add complexity. Paxos, 2PC, etc.
--Kyle
On 10/30/2011 09:42 AM, Les Mikesell wrote:
On Sun, Oct 30, 2011 at 10:43 AM, Alexander Sicular<[email protected]> wrote:
Greetings Justin,
IMHO, AFAIK, IANAL, etc. "is it ok?" really boils down to whatever you're ok
with, can program, can understand, is within you're budget, can implement
and/or do all of the above within your own timeline. I think it is always
true that the number of opinions you will get is more than the number of
participants in the conversation. Ergo, filter all contributions through the
lense of: Go with what you know. Coming here for advice is fine but like
preventing wildfires, only you know your use case.
That said, you may want to check out using a message queue to control the
asynchronous, eventually consistent data model I feel you feel you are
leaning towards.
I don't see how pushing the problem elsewhere helps. Even if your
message queue orders a set of updates in the right sequence, riak does
not have a mechanism to ensure that they go into the db in that order
and a delete might happen before the insert intended to be done first
but actually happening concurrently - unless you make the writes wait
for all nodes on every operation. I think riak has a concept of a
partition 'owner' node, but it is used only in the data migration
process for failover and node adds/removes, not to give ordinary
writes an atomic property.
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
