[SERVER-54598] Investigate whether SBE needs to behave differently if WriteConflictException is thrown Created: 17/Feb/21  Updated: 29/Oct/23  Resolved: 29/Apr/21

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: 5.0.0-rc0

Type: Task Priority: Major - P3
Reporter: David Storch Assignee: Ian Boros
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-55101 [SBE] WriteConflictException thrown i... Closed
Backwards Compatibility: Fully Compatible
Sprint: Query Execution 2021-04-19, Query Execution 2021-05-03
Participants:

 Description   

The classic execution engine has logic (implemented with the NEED_YIELD return code) to allow query execution to tolerate a WriteConflictException thrown from the storage layer. In short, if WCE is thrown by an operation on a storage cursor, the exception is caught and propagated to the PlanExecutorImpl via NEED_YIELD. The plan executor undergoes the yielding process and then picks up query execution where it left off.

No such logic exists today in the SBE engine, and SBE is generally unable to resume if an arbitrary exception is thrown. We should investigate whether SBE actually needs to tolerate SBE in the way that the classic engine does, and if so figure out how this could be achieved. My understanding is that WCE during find operations is either exceedingly rare or impossible (it is called a "write conflict" after all), so perhaps we could just retry the query from the beginning with a retry loop at a very high level?



 Comments   
Comment by Githook User [ 28/Apr/21 ]

Author:

{'name': 'Ian Boros', 'email': 'ian.boros@mongodb.com', 'username': 'puppyofkosh'}

Message: SERVER-54598 Disable write_conflict_wildcard when SBE is enabled
Branch: master
https://github.com/mongodb/mongo/commit/64c485b5e1582af642b9a2e603e4277865b8c7dc

Comment by Ian Boros [ 13/Apr/21 ]

After some discussion with Louis from storage execution, I believe that we're safe to do nothing here, for now. The summary is that we should not have to handle a WCE for a storage-level transaction that do only reads. However, it's possible this will change (see SERVER-44870).

technically, no WCEs are not expected for reads. In practice, sometimes, but never for read-only operations. In the future: maybe

I am going to leave this ticket open since we still need to do something about the write_conflict_wildcard test (which triggers a WCE during a read via fail point).

Comment by Anton Korshunov [ 06/Apr/21 ]

ReenableĀ jstests/noPassthrough/write_conflict_wildcard.js once this issue is addressed.

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