[SERVER-53333] ephemeralForTest does not throw WCE on commit Created: 10/Dec/20  Updated: 27/Oct/23  Resolved: 25/Jan/21

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Janna Golden Assignee: Geert Bosch
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File eft_repro.patch    
Operating System: ALL
Sprint: Execution Team 2021-01-25
Participants:

 Description   

I wrote a couple of dbtest cases each running concurrent storage transactions, and was expecting us to throw a WCE on the WUOW commit in each case when running on EFT. Instead, we succeed in committing both storage transactions in both test cases. I modified a dbtest I recently added and attached the repro here. The tests in the repro succeed as written, and I'd expect them to throw and crash instead.



 Comments   
Comment by Janna Golden [ 25/Jan/21 ]

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.

Comment by Geert Bosch [ 25/Jan/21 ]

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.

Comment by Geert Bosch [ 25/Jan/21 ]

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.

Generated at Thu Feb 08 05:30:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.