misaka at pobox.com
Thu Jul 15 17:06:41 EDT 2010
Thanks for the feedback. Just thought I'd mention we're aiming to go
ahead with a strategy of serialising the transactions before they hit
Riak. We figure it'll be easier to solve than trying to do conflict
On 14 July 2010 14:00, Justin Sheehy <justin at basho.com> wrote:
> On Wed, Jul 14, 2010 at 5:25 AM, Misha Gorodnitzky <misaka at pobox.com> wrote:
>> I don't suppose there are any examples anywhere of how people have
>> approached conflict resolution with RIak? That would be useful to help
>> people understand how to approach it ... maybe a section on the wiki
>> could be dedicated to it.
> This is a great idea. We'll find a right place to present this that's
> easier to find.
>> In our particular case, we're trying to store transactions in Riak and
>> need to guard against a transaction being placed on a balance that has
>> reached 0. The problem we keep running into is race conditions between
>> when we record the transaction and when we update the cached balance
>> value. Any suggestions on how this has been, or can, be solved would
>> be appreciated.
> I suggest that you solve this similarly to the way that banks have
> been doing so for far longer than there have even been computers
> involved. Each transaction should be (at least) a unique identifier,
> a time, and the amount being added or subtracted to the balance. This
> way (in addition to storing what you believe the balance to be at any
> time) you can reconcile balances even if you get some transactions
> late or multiple times.
> More specifics than that will depend a lot on your application, but
> the key here is that you can make things much neater in situations
> where your actions can be commutative and idempotent. That's why you
> store the transaction itself instead of just the balance, and a unique
> id so that you don't repeat yourself.
> Best of luck,
More information about the riak-users