stephenmcd / curiodb

Distributed NoSQL Database
http://curiodb.jupo.org
BSD 2-Clause "Simplified" License
511 stars 47 forks source link

commands in transaction executed not sequently #23

Open meteorgan opened 8 years ago

meteorgan commented 8 years ago

test 1: mget number1 number3 should return 4 15. redis 127.0.0.1:6370> get number3 "15" redis 127.0.0.1:6370> multi OK redis 127.0.0.1:6370> mget number1 number3 QUEUED redis 127.0.0.1:6370> set number3 20 QUEUED redis 127.0.0.1:6370> exec 1) 1) "4" 2) "20" 2) OK

test 2: dbsize in transaction should return 11, not 12. redis 127.0.0.1:6370> dbsize (integer) 11 redis 127.0.0.1:6370> multi OK redis 127.0.0.1:6370> dbsize QUEUED redis 127.0.0.1:6370> set number2 1 QUEUED redis 127.0.0.1:6370> exec 1) (integer) 12 2) OK

the reason is the commands are sent sequently, but not executed sequently.

stephenmcd commented 8 years ago

I think a good way to fix this will be to have the MULTI/EXEC list of commands get put inside a simple Lua script that we can generate when EXEC is called. The Lua script will just call redis.call sequentially and build a list (Lua table) of responses. If we do this, I think will simplify a lot of the current code around transactions since in Scala we only ever deal with one command being run (EVAL/EVVALSHA).

What do you think? The other option is to rewrite the current transaction code to go from "send commands -> await all replies" to "send command -> await reply -> send command -> await reply -> etc".

There might be some overhead compiling/running the Lua script, but it will simplify the code a lot.

meteorgan commented 8 years ago

I don't know much about Lua script, i will look at it later. In your second solution, your don't need to send all commands sequently, the problem is commands with multi key and some commands like dbsize executed by clientNode may conflict with other commands, but implementing this is more complicated.

And there are other problems about the transaction, i will post it later.