MARKLOGIC SERVER

MarkLogic starts by parsing and indexing the document contents, converting the
document from serialized XML to a compressed binary fragment representation of
the XML data model (strictly, the XQuery Data Model 9 ). The fragment is added to the
in-memory stand. At this point, the fragment is considered a nascent fragment—a term
you'll see sometimes on the Admin Interface status pages. Being nascent means it exists
in a stand but hasn't been fully committed. (On a technical level, nascent fragments'
creation and deletion timestamps are both set to infinity, so they can be managed by the
system while not appearing in queries prematurely.) If you're doing a large transactional
insert, you'll accumulate a lot of nascent fragments while the documents are being
processed. They stay nascent until they've been committed.
At some point, our statement completes successfully, and the request is ready to
commit. MarkLogic obtains the next timestamp value, journals its intent to commit
the transaction, and then makes the fragment available by setting the creation
timestamp for the new fragment to the transaction's timestamp. At this point, it's a
durable transaction, replayable in the event of server failure, and it's available to any
new queries that run at this timestamp or later, as well as any updates from this point
forward (even those in progress). As the request terminates, the write lock gets released.
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 is written to disk. Our document is
now in an on-disk stand.
Sometime later, based on merge algorithms, 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.
At some point, a new request makes a change to the document, such as with an
xdmp:node-replace() call. The request making the change 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. If another write lock were already
present on the URI from another executing update, the read lock would have blocked
until the other write lock released. If another read-lock were already present, the lock
promotion to a write lock would have blocked.
Assuming that 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
9 The data model is defined in exhaustive detail at XQuery and XPath Data Model and may differ from the
serialized format in many ways. For example, when serialized in XML, an attribute value may be surrounded
by single or double quotes. In the data model, that difference is not recorded.
42