[SERVER-35613] Two-phase drop can prevent subsequent transaction from acquiring locks. Created: 15/Jun/18 Updated: 16/Jun/18 Resolved: 16/Jun/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.0.0-rc4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
Version 4.1.0-353-gc741174b3. Running a C Driver test that does the following:
Same in 4.0.0-rc4. Works if I do not drop the collection immediately beforehand. |
| Comments |
| Comment by A. Jesse Jiryu Davis [ 15/Jun/18 ] |
|
Thanks Dianna - the majority writeConcern fixes my problem. You can close this duplicate, and I have no opinion about the timeout value. |
| Comment by Dianna Hohensee (Inactive) [ 15/Jun/18 ] |
|
Drop is two-phase, asynchronously taking a database exclusive lock. Transactions meanwhile have lock request timeout overrides to prevent deadlocks. Adding a majority writeConcern to the drop cmd will make the drop cmd wait for the asynchronous second phase to finish before returning, making sure the subsequent transaction operation will not potentially run into it. |
| Comment by Githook User [ 15/Jun/18 ] |
|
Author: {'username': 'ajdavis', 'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com'}Message: See |
| Comment by William Schultz (Inactive) [ 15/Jun/18 ] |
|
This is probably the same issue described in |