[SERVER-38404] lockComplete can incorrectly skip checking if the operation context was killed, if the lock is granted quickly Created: 05/Dec/18 Updated: 29/Oct/23 Resolved: 14/Dec/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.7 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Samyukta Lanka | Assignee: | Louis Williams |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | prepare_interruptibility, uninterruptibleLockGuardRemoval | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Sprint: | Storage NYC 2018-12-17 |
| Participants: |
| Description |
|
When waiting for the request to be granted when calling lockComplete, the predicate could initially return true when we call waitForConditionOrInterrupt. This would mean that we never check if the operation context was killed, and so the operation continues even if it had been killed. This can happen if the lock request was granted very quickly after lockComplete is called. |
| Comments |
| Comment by Githook User [ 14/Dec/18 ] |
|
Author: {'username': 'louiswilliams', 'email': 'louis.williams@mongodb.com', 'name': 'Louis Williams'}Message: |
| Comment by Samyukta Lanka [ 11/Dec/18 ] |
|
louis.williams, yes that is the scenario we want to prevent from happening. |
| Comment by Louis Williams [ 06/Dec/18 ] |
|
The issue is specifically related to how the database handles shutdown with prepared transactions. samy.lanka correct my if this is wrong. thread A: command dropCollection "test"
This scenario is problematic because we should not be allowed to perform DDL operations on a database after transactions have been prepared. |