[DOCS-5976] fsyncLock documentation does not discuss behaviour of multiple locks Created: 05/Aug/15 Updated: 30/Oct/23 Resolved: 29/Mar/18 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Victor Hooi | Assignee: | Kay Kim (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 5 years, 45 weeks, 6 days ago | ||||||||
| Description |
|
If you issue multiple calls to db.fsyncLock, each invocation takes a separate lock, and you need to ensure you pair an exact number (or greater number) of matching db.fsyncUnlock commands to unlock things. This is not necessarily intuitive behaviour - many people might assume there are only two states - locked and unlocked, and that multiple calls to db.fsyncLock whilst locked are simply idempotent (and similarly for db.fsyncUnclock). The output of the commands also doesn't give any clues about this behaviour either:
Nor is it mentioned on either the documentation for fsync or db.fsyncLock:
Is it possible to document this behaviour in either/both of those locations? |
| Comments |
| Comment by Githook User [ 29/Mar/18 ] |
|
Author: {'email': 'kay.kim@10gen.com', 'name': 'kay', 'username': 'kay-kim'}Message: |
| Comment by Githook User [ 29/Mar/18 ] |
|
Author: {'email': 'kay.kim@10gen.com', 'name': 'kay', 'username': 'kay-kim'}Message: |
| Comment by Kay Kim (Inactive) [ 29/Mar/18 ] |
|
Will do as part of 9265 |