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.
--
Les Mikesell
[email protected]
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
