Disk storage and real transactions under Redis compatible protocol | Hacker News Reader

Disk storage and real transactions under Redis compatible protocol

serenitydb.org

34 pointspmwkaa6 comments

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?

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

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

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.

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.

Are the transactions distributed?

Reply on news.ycombinator.com