curiodb icon indicating copy to clipboard operation
curiodb copied to clipboard

lost update in transactions

Open meteorgan opened this issue 9 years ago • 2 comments

#/usr/bin/env python
#coding: utf-8

import redis

from multiprocessing import Process

def get_value(host, port, var):
    r = redis.Redis(host=host, port=port)
    return r.get(var)

def lost_update(host, port, var):
    r = redis.Redis(host=host, port=port)
    pipe = r.pipeline()
    pipe.incr(var, 1)
    pipe.execute()
    #for i in range(0, 10):
    #    pipe.incr(var, 1)
    #    pipe.execute();


if __name__ == "__main__":
    host = '127.0.0.1'
    port = 6370
    var = "test1"
    print get_value(host, port, var)

    p1 = Process(target=lost_update, args=(host, port, var))
    p2 = Process(target=lost_update, args=(host, port, var))
    p1.start()
    p2.start()
    p1.join()
    p2.join()

    print get_value(host, port, var)

run the above code, output:

43
44

if you uncomment the code, run it, sometimes it will response timeout.

problem 1: when one keyNode send _MULTI to itself(node() ! command), if may has receive another _MULTI from another clientNode, so both clientNodes won't wait(inTransaction will fail), they will update a data node concurrently, and update at their own data version.

problem 2: two clientNode can send _MULTI to every keyNode at the same time, so some keyNodes may receive _MULTI from clientNode1, some keyNodes receive _MULTI from clientNode2, and no clientNodes will finish the transaction.

and i have a question, why keynodes should have multi-version?

meteorgan avatar Feb 28 '16 05:02 meteorgan

Started looking at this, I think first and foremost your question needs attention:

and i have a question, why keynodes should have multi-version?

I think the idea here is that different transactions should see their own view of keys that do or don't exist, but it has a problem, since the value of a keynode is map[string, entry] and entry contains the actorref - the actorref shouldn't be duplicated for each transaction, these should be global within a single keynode, so that needs fixing first.

Your script highlights this problem, because at first run, two transactions try to create the key, so they both try and create a new actor with the same path, which fails.

stephenmcd avatar Mar 17 '16 22:03 stephenmcd

BTW I'm going to first work on that fix, then look at the other issues you raised, just wanted to give a progress update. :-)

stephenmcd avatar Mar 17 '16 22:03 stephenmcd