[SERVER-43309] Transaction eagerly locks document causing WriteConflict Created: 13/Sep/19  Updated: 27/Oct/23  Resolved: 13/Sep/19

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

Type: Bug Priority: Major - P3
Reporter: Ronald Chen Assignee: Danny Hatcher (Inactive)
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File tx-eagerly-locks.js    
Operating System: ALL
Steps To Reproduce:

Run attached file.

Expected, some-event state updated to right

Actual, output

-4
-3
-2
-1
0
1
2
3
{ MongoError: WriteConflict... 

Participants:

 Description   

mongodb server 4.0.3
npm client mongodb 3.3.1
 
When two sessions are trying to update the same document, if the first session updates the document, attempt by the second session to update the document will fail with WriteConflict, even if the first session has not committed the transaction yet.
 
Attached is code sample which reproduces this case. The sample code prints numbers so you can see which line of code causes the WriteConflict.
 
I believe this is a bug because imagine if the aliceSession will throw an error before ever committing the transaction. Why should bobSession be punished with a WriteConfilct when aliceSession will never commit?



 Comments   
Comment by Danny Hatcher (Inactive) [ 13/Sep/19 ]

Snapshot isolation guarantees that every transaction, conceptually, runs against its own, consistent "snapshot" of the database, which reflects the effects of all previously committed transactions. Every transaction performs its reads and writes against this snapshot, adjusting for the effects of any writes executed inside the transaction. Snapshot isolation enforces a policy for serializing writes between transactions known as the "First Updater Wins" rule. Intuitively, this rule states that concurrent transactions are not allowed to write to the same document. Transactions under snapshot isolation are defined to be "concurrent" if their transactional lifetimes overlap. The rule is enforced via an optimistic concurrency control mechanism, as opposed to a pessimistic one i.e. locking the document. If two concurrent transactions T1 and T2 write to the same document, only the first writer will succeed. So, for example, if transaction T2 tries to write to a document already written to by T1 this will cause T2's write to fail with a "WriteConflict" error, and transaction T2 will be aborted.

Given the above, this functionality is working as designed and we would expect to see a write conflict in your test case. As such, I will close this ticket.

Comment by Ronald Chen [ 13/Sep/19 ]

another reason why I consider this a bug is the writes are observable by other sessions before they are committed

Comment by Ronald Chen [ 13/Sep/19 ]

btw, sample code was using

node v10.15.3

npm 6.4.1

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