[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:
Depends
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 command acquires the global write lock, blocking all write operations and all read operations on that node
  • The command flushes to disk all of the changes in all of the files used by MongoDB

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.)

Generated at Thu Feb 08 07:39:30 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.