[SERVER-23551] $isolated updates and deletes should use WRITE_CONFLICT_RETRY_ONLY yield policy Created: 05/Apr/16  Updated: 04/Jan/17  Resolved: 21/Apr/16

Status: Closed
Project: Core Server
Component/s: Write Ops
Affects Version/s: None
Fix Version/s: 3.3.5

Type: Bug Priority: Major - P3
Reporter: Mathias Stearn Assignee: Mathias Stearn
Resolution: Done Votes: 0
Labels: bkp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.2
Sprint: Integration 13 (04/22/16)
Participants:

 Description   

Currently they use YIELD_MANUAL which prevents automatic resuming after hitting a WCE. This causes the operation to start over from scratch, or report failure to the user in the case of a multi-update.



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

Author:

{u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}

Message: SERVER-23551 $isolated writes should use WRITE_CONFLICT_RETRY_ONLY
Branch: master
https://github.com/mongodb/mongo/commit/b95db102cadf57661e53ae6aa81c4ab9a1254a16

Comment by J Rassi [ 06/Apr/16 ]

No. The current behavior is not correct because the catch block for WriteConflictException for YIELD_MANUAL multi-updates/deletes is outside of the collection lock acquisition, which means that they release their exclusive collection lock on each WriteConflictException. The proposed behavior is correct because the exclusive collection lock will be held for the length of the entire operation, even though the operation may be retried from the beginning when a WriteConflictException is encountered.

Comment by Andy Schwerin [ 06/Apr/16 ]

Isn't the current behavior correct?

Comment by J Rassi [ 05/Apr/16 ]

Per discussion, in some cases this can cause reads to observe the intermediate state of an $isolated multi-delete, when the WiredTiger storage engine is being used and a WriteConflictException is thrown.

Comment by Mathias Stearn [ 05/Apr/16 ]

I'm taking this since it simplifies my work on SERVER-23128.

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