|
geert.bosch right, Louis had explained to me the difference between how we handle WCEs in WT versus EFT. What I found (and what is in the attached repro) is that we are not getting a conflict at commit time when running on EFT when doing a no-op update in one transaction and a delete in another. Let me know if I've misunderstood something, if not I think we should re-open this ticket.
|
|
janna.golden, please let me know if this behavior blocks your work, so we can discuss what our team can do to help. In discussion with the storage engines team, it has become clear that we should have a separate "reserve" API, but we still need to figure out what the exact semantics of that API are.
|
|
The EFT storage engine resolves write conflicts on commit, unlike WiredTiger which doesn't permit two open transactions with uncommitted transactions to the same object. The difference is intentional, as it has been an objective to allow alternative implementations of the Storage Engine API. One of the drawbacks of the WT model is that it allows for situations where there may be no forward progress: say, 100 clients try to update the same 100 index entries, but in a different order. Such scenarios become more likely with long-running transactions.
A no-op update that replaces an object with a new, but identical, version of that object should still cause a conflict at commit time. As per a recent discussion with the storage engines team, we'll probably indeed want a "reserve" function for your use-case, which will have different semantics than the no-op use case.
|