[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:
Duplicate
duplicates SERVER-34195 Support speculative readConcern behav... Closed
Assigned Teams:
Replication
Operating System: ALL
Participants:

 Description   

    ses = db.getMongo().startSession()
    dbs = ses.getDatabase("test")
 
    printjson(dbs.createCollection("c", {writeConcern: {w: "majority"}}))
 
    print("TRANSACTION 1")
    printjson(ses.startTransaction())
    printjson(dbs.c.insert({_id: 0}))
    printjson(ses.commitTransaction())
 
    print("TRANSACTION 2")
    printjson(ses.startTransaction())
    printjson(dbs.c.insert({_id: 1}))
    printjson(ses.commitTransaction())

The second transaction fails with

assert: command failed: {
	"operationTime" : Timestamp(1524048246, 2),
	"ok" : 0,
	"errmsg" : "WriteConflict",
	"code" : 112,
	"codeName" : "WriteConflict",
	"$clusterTime" : {
		"clusterTime" : Timestamp(1524048246, 3),
		"signature" : {
			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
			"keyId" : NumberLong(0)
		}
	}
}



 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 SERVER-34195. Once SERVER-34195 is complete you should no longer encounter this issue.

Comment by Daniel Gottlieb (Inactive) [ 18/Apr/18 ]

If SERVER-34195 means that the default read concern for transactions will change to last-applied then I think it should be ok.

That's my understanding.

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.

I believe this is a major motivation for doing SERVER-34195.

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 SERVER-34195.

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:

var ses = db.getMongo().startSession()
var dbs = ses.getDatabase("test")
 
printjson(dbs.createCollection("c", {writeConcern: {w: "majority"}}))
 
print("TRANSACTION 1")
printjson(ses.startTransaction({readConcern: {level: "snapshot"}, writeConcern: {w: "majority"}}))
printjson(dbs.c.insert({_id: 0}))
printjson(ses.commitTransaction())
 
print("TRANSACTION 2")
printjson(ses.startTransaction({readConcern: {level: "snapshot"}, writeConcern: {w: "majority"}}))
printjson(dbs.c.insert({_id: 1}))
printjson(ses.commitTransaction())

Sending to the Repl team to comment on whether we have plans to make majority writeConcern the default for multi-statement transactions.

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