Document Lifecycle in MarkLogic

Moderator: Reach-Native-gp

Post Reply
Posts: 16
Joined: Thu Oct 01, 2020 4:13 pm

Document Lifecycle in MarkLogic

Post by rahulburman »

What is the document life cycle in a MarkLogic system?

Posts: 21
Joined: Thu Oct 01, 2020 4:10 pm

Re: Document Lifecycle in MarkLogic

Post by amitgope »

This would include from inserting or loading a document to deleting a document from the MarkLogic.
1. A document load request acquires a write-lock for the target URI as part of the xdmp:document-load() function call. If any other request is already doing a write to the same URI, our load will block for it, and vice versa.
2. MarkLogic starts by parsing and indexing the document contents, converting the document from XML to a compressed binary fragment representation. The fragment gets added to the in-memory stand.
3. At this point the fragment is considered a nascent fragment
4. Our document lives for a time in the in-memory stand, fully queryable and durable, until at some point the in-memory stand fills up and gets written to disk.The document is now in an on-disk stand
5. The on-disk stand will get merged with some other on-disk stands to produce a new on-disk stand. The fragment will be carried over, its tree data and indexes incorporated into the larger stand. This might happen several times.
6. If a node replace is executed in the document, the request making the change first obtains a read-lock on the URI when it first accesses the document, then promotes the read-lock to a write-lock when executing the xdmp:node-replace() call.
7. If the update request finishes successfully, the work runs similar to before: parsing and indexing the document, writing it to the in-memory stand as a nascent fragment, acquiring a timestamp, journaling the work, and setting the creation timestamp to make the fragment live. Because it's an update, it has to mark the old fragment as deleted also, and does that by setting the deletion timestamp of the original fragment to the transaction timestamp. This combination effectively replaces the old fragment with the new. When the request concludes, it releases its locks. Our document is now deleted, replaced by the new version.

Post Reply