Yes, this is one I just thought of and was going to ask if it made sense. In order to write A first, you'd need B's key id to be generated outside of Riak (e.g. client generated UUID or snowflake or something). Then you can use a job queue with retries that can simply mash the writing of B until it succeeds. "Eventually" the A->B relationship would exist, and in the meantime the application would need to cope with a possible dangling pointer (A pointing to a nonexistent key).
On Sunday, October 30, 2011 09:49:00 AM Aphyr wrote: > 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 _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
