[SERVER-17770] CollectionLock::relockWithMode() shouldn't relock database Created: 27/Mar/15 Updated: 19/Sep/15 Resolved: 25/Apr/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency |
| Affects Version/s: | None |
| Fix Version/s: | 3.1.2 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | J Rassi | Assignee: | Geert Bosch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Quint Iteration 3.1.2 |
| Participants: |
| Description |
|
The CollectionLock undocumented method relockWithMode() confusingly relocks the associated database lock as a side effect. This is unintuitive and often introduces scenarios where redundant locks are held. For example: supposing a client holds database IX and collection IX. It is not expected that relocking the collection lock in X would also relock the database lock in X as a side effect (in which the reacquisition of the collection lock becomes redundant). This method was introduced to facilitate the implicit collection creation path, and so existing callers that rely on this behavior will need an audit. This implicit collection creation use case should be kept in mind when deciding how to further improve the locking API. |
| Comments |
| Comment by Githook User [ 25/Apr/15 ] |
|
Author: {u'username': u'GeertBosch', u'name': u'Geert Bosch', u'email': u'geert@mongodb.com'}Message: Previous version was confusing. This really has just a single purpose, so |