Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lost update in transactions #24

Open
meteorgan opened this issue Feb 28, 2016 · 2 comments
Open

lost update in transactions #24

meteorgan opened this issue Feb 28, 2016 · 2 comments

Comments

@meteorgan
Copy link
Contributor

#/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?

@stephenmcd
Copy link
Owner

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
Copy link
Owner

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. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants