[SERVER-34532] Spurious WriteConflict error with multi-statement transactions Created: 18/Apr/18 Updated: 06/Dec/22 Resolved: 18/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | 3.7.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Bruce Lucas (Inactive) | Assignee: | Backlog - Replication Team |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Replication
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
The second transaction fails with
|
| Comments |
| Comment by Spencer Brody (Inactive) [ 18/Apr/18 ] | ||||||||||||||
|
Dan is correct, this was one of the main motivators for deciding to push back feature-complete for transactions for 4.0 to deliver | ||||||||||||||
| Comment by Daniel Gottlieb (Inactive) [ 18/Apr/18 ] | ||||||||||||||
That's my understanding.
I believe this is a major motivation for doing | ||||||||||||||
| Comment by Bruce Lucas (Inactive) [ 18/Apr/18 ] | ||||||||||||||
|
I think you're saying that developers can see write conflicts due to implementation details that have nothing to do with conflicting updates to application documents. If so this would seem to make the notion of write conflict very difficult for a developer to reason about. | ||||||||||||||
| Comment by Daniel Gottlieb (Inactive) [ 18/Apr/18 ] | ||||||||||||||
|
The WCE is on updating a unique index in the transactions table. I think Andy's assessment is correct. What's tricky (IMO) about the scenario is that the transactions table gets the same majority read visibility rules applied to it, which result in this WCE (a WT update node on top of a non-visible update node). | ||||||||||||||
| Comment by Andy Schwerin [ 18/Apr/18 ] | ||||||||||||||
|
This is duplicate of | ||||||||||||||
| Comment by James Wahlin [ 18/Apr/18 ] | ||||||||||||||
|
I believe occurs because we are not specifying majority writeConcern at transaction start. The following executes without generating a WriteConflict:
Sending to the Repl team to comment on whether we have plans to make majority writeConcern the default for multi-statement transactions. |