[DOCS-785] Docs are not complete on the behavior of db.fsyncLock() Created: 21/Nov/12 Updated: 21/Nov/12 Resolved: 21/Nov/12 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | William Zola | Assignee: | Sam Kleinman (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
http://docs.mongodb.org/manual/reference/method/db.fsyncLock/ |
||
| Issue Links: |
|
||||
| Participants: | |||||
| Days since reply: | 11 years, 13 weeks ago | ||||
| Description |
|
The term 'database' in the current documentation is ambiguous When you run the db.fsyncLock() command, the following happens:
The global write lock will continue to be held until the command 'db.fsyncUnlock()' is run. |
| Comments |
| Comment by Sam Kleinman (Inactive) [ 21/Nov/12 ] |
|
Yes, though this isn't a database command, and more a shell helper behavior documentation glitch, exposed by 2.2. The original language used "database" to mean "instance" which wasn't confusing before 2.2, but is now... Agreed about documenting locks and commands, but the solution to that issue is outside of the scope (and likely orthogonal) to this ticket. |
| Comment by Sam Kleinman (Inactive) [ 21/Nov/12 ] |
|
(commit's published. the docs now reflect an alternate reality branch for a few days while we wait for the write concern change, but the commit will post to this thread next week.) |