Disk storage and real transactions under Redis compatible protocol

by pmwkaa • 11 years ago

34 6 11 years ago

Looks pretty good. The storage backend must have come a long way since the last time I checked it, at the time it crashed every time I accessed it from multiple threads.

misframer2• 11 years ago

In the "Conflict Resolving" section on the home page, we see that client A and client B are both executing only writes in transactions. Why would they conflict since any serialization order is possible?

markelliot• 11 years ago

Yeah, read/write conflicts don't seem to actually generate conflicts. e.g. imagine two processes p1 and p2:

    p1: SET a 1
    p1: BEGIN
    p1: GET a
    p1: SET z 1  # imagine this were contingent on reading a
    p2: BEGIN
    p2: SET a 2
    p2: COMMIT
    p1: COMMIT   # expect conflict, but don't get one
    p1: GET a    # returns 2
    p2: GET z    # returns 1

misframer2• 11 years ago

Nice find! I just tried it out myself and got the same result. I wonder how well this is tested...

pmwkaa• 11 years ago

Yes you are right. What you pointed out is a write-skew anomaly which is specific for a Snapshot isolation. The only way to fix this is to upgrade to Serialization level of isolation (SSI for example), which is hopefully will be implemented. Thanks.

shin_lao• 11 years ago

Are the transactions distributed?

Disk storage and real transactions under Redis compatible protocol

Related Stories