Alexander> This would have to be implemented in application space... The application 'if then if then if then' proposals are ugly, cumbersome and unsafe in case of client crash.
Atomicity is better provided at the protocol level, and I don't see why a distributed store can't provide such a convenient mechanism. A naïve implementation would be for riak to attach a session status to each object in the store. The statut would be type Status = Commited | InSession SessionID where SessionId is a unique id. If we need nested sessions, it would just have to be a list of SessionIds type Status = Commited | InSessions [ SessionID ] Next, any connexion to riak can be done in a session (or in nested sessions), which is nothing else than a property attached to requests. type Session = NoSession | InSession SessionID or, for nested sessions : type Sessions = [ SessionID ] For the rest of this proposal, I'll take the case of flat single session. Any query performed by any client will return every objects for which Status is either Commited, or (InSession session_id) , where session_id is obviously the id of the query session. That provides isolation, so that concurrent queries won't see the data until commited, while session queries will see them. Any insertion will have its status set to (InSession session_id) until riak receives the order to commit this session_id, at which point it will turn these objects status to Commited. There is a short window here where the data could be in an inconsistent state, but I doub't it matters much in riak case, and I'm confident that they are tricks to limit its effect. If riak receives a rollback instruction, it just deletes objects having the session_id. If it never receives it, it can decide to cleanup objects after a configurable timeout. Most of this proposal could probably be implemented by riak clients, but a riak server support would allow better performance by doing efficient book-keeping, as well as providing a unified and well supported protocol for such operations. Just like search, secondary indices or luwak ... -- Paul _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
