[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: |
|
|||||||||
| Operating System: | ALL | |||||||||
| Steps To Reproduce: | Run attached file. Expected, some-event state updated to right Actual, output
|
|||||||||
| Participants: |
| Description |
|
mongodb server 4.0.3 |
| 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 |