[DOCS-10754] Incomplete documentation in FAQ on concurrency Created: 05/Sep/17 Updated: 30/Oct/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual, Server |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Prasad Pillalamarri | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 1 year, 14 weeks, 2 days ago |
| Epic Link: | DOCSP-1769 |
| Description |
|
at the location https://docs.mongodb.com/master/faq/concurrency/index.html in documentation MVCC is not coming out accurately. There are several questions from Partners, Customers to prove or talk on concurrency on MongoDB/WT. Official documentation would help to share that message. If the messaging is around - along with few diagrams it would help. Multi-Version Concurrency Controls (MVCC) • Updates don’t happen in-place; a new copy is made • The other write will will be retried based on the writes waiting on the update skip queue |
| Comments |
| Comment by Education Bot [ 31/Oct/22 ] |
|
Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you! |
| Comment by Geert Bosch [ 05/Sep/17 ] |
|
Hi Prasad, thank you for your suggestions on improving our documentation. Reading your suggestions, it seems that you view the documentation more as incomplete rather than inaccurate. We could indeed be more clear and state that WiredTiger uses "opportunistic multi-version concurrency control (MVCC)" rather than just "opportunistic concurrency control", and explain that old versions of data can still be read by active operations while new ones are created using a diagram. Note that we do still use intent locks, so an update in WiredTiger still can show waits to acquire locks in some situations, such as those affecting the catalog (index/collection creation and drops). We don't have specific read- and write-threads, but multi-document operations, such as multi-updates or large batch inserts, may "see" data change during the operation. The comment about in-place updates really doesn't have much to do with concurrency, but rather about how WiredTiger creates new checkpoints and writes data back to durable storage. Concurrency is all about the in-memory format. I'm not sure how helpful it is to give much detail on that in the general documentation, as such internal details often lead to confusion. There is no concept of writes waiting on an update skip queue: a skip list is used to maintain the multiple versions of a document, but updates will not queue. Internal data structures such as these skip lists are also subject to change without notice. For example, development versions of MongoDB's WiredTiger storage engine now support storing partial document updates. Hope this helps, and thanks again for your comments. |