-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[BUG]: serializable behavior is broken #2057
Comments
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? |
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 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:
The text was updated successfully, but these errors were encountered: