Open al8n opened 4 months ago
We provide only SSI: Serializable Snapshot Isolation. Did you turn managed mode off? By default, we don't do that. Only in managed mode we provide this SSI.
We provide only SSI: Serializable Snapshot Isolation. Did you turn managed mode off? By default, we don't do that. Only in managed mode we provide this SSI.
Hi, I have not turned the managed mode off. I just use the default database options which is used for testing purpose.
Can you try it once after turning managed mode off?
Can you try it once after turning managed mode off?
Even when I turn the managed mode off, the test case still does not work. Could you try it in case I missed something? It seems that the transaction model is OCC but not really SSI.
I think this is because, in a badger transaction commit, the code checks if two transactions have read-write conflict, if txn1 read [a1, a2, b1, b2], and write [b3], txn2 read [a1, a2, b1, b2] and write [a3]. The current transaction implementation will think this is no problem because of the two transactions do not write the key which is in reads.
In some situations, this is correct, but if the behavior in txn1: write [b3]
and txn2: write [a3]
is based on the sum of the current values in the database, then it becomes wrong because after the txn2 commit, the sum of the values in the database has been changed. So the condition to write [b3] in txn1 is changed, and in respect of SSI, the commit of txn1 should fail.
In the provided example:
The essence of the problem is that each transaction's decision to write is based on a snapshot of the database that becomes outdated once the other transaction commits. This is precisely the kind of issue that Serializable Snapshot Isolation (SSI) aims to prevent.
Why the current model in BadgerDB might miss this?
BadgerDB’s OCC checks for read-write conflicts by examining if any of the read keys of a transaction have been modified before it commits. However, this model does not account for logical dependencies where the decision to write a new key is based on the values of read keys rather than the keys themselves. This situation can lead to anomalies where:
Enhancing the model to handle this case
To handle this scenario in BadgerDB, the conflict detection mechanism needs to be sophisticated enough to understand these indirect dependencies. Here's a conceptual approach to extending the BadgerDB model:
In conclusion, this is a classic problem in concurrent transaction systems where two transactions don't directly write to the same data items but their operations are logically interdependent based on the read data. When such dependencies exist, it's possible for transactions to commit changes that, while individually valid, result in inconsistencies when combined.
Please correct me if I am wrong @harshil-goel, thanks!
This issue has been stale for 60 days and will be closed automatically in 7 days. Comment to keep it open.
Hi! Currently, the transaction model cannot handle this kind of write skew: https://wiki.postgresql.org/wiki/SSI#Intersecting_Data.
What steps will reproduce the bug?
Error trace: