[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)
– Keeps old versions of data while creating new ones
– No locks; read/write threads see data as it existed when the thread started

• Updates don’t happen in-place; a new copy is made
• Reads/writes see only data committed before they begin • If writes conflict, only one will “win”
• When writes happen: The new version of the document is first prepared

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

Generated at Thu Feb 08 08:01:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.