MARKLOGIC SERVER

Figure 9: During a commit involving multiple D-nodes, one D-node acts as the coordinator (1). First,
the system creates the nascent documents (with timestamps set to infinity) (2) and the coordinator writes
a distributed begin entry to its journal (3). During the first phase of the commit, participating nodes signal
that their updates have occurred and they are prepared to commit (4). Only after all hosts confirm
does the second phase occur, when timestamps are updated and documents go live (5). If any nodes
signal that they are unprepared, MarkLogic rolls back the transaction. Finally, the coordinator writes a
distributed end entry to the journal and the commit is complete (6).
Locking with Forest Placement
By default, MarkLogic chooses where to place new documents according to a selected assignment policy.
Insertion calls can also request that a document be placed in a specific forest. There are two ways to do this.
First, a document insertion call can include forest placement keys, specified as forest IDs (as parameters to the
insertion call), to target the document into a particular forest. In this event, locks are managed the same as if
there were no placement keys, by the forest selected by the deterministic hash. This ensures that two concurrent
forest placements against two different forests will respect the same lock. Second, a document insertion call can
execute within an "in-forest eval" (using an undocumented parameter to the eval() function) whereby all
executed code runs only within the context of the selected forest. With this more advanced technique only the
selected forest manages the lock. This executes a bit faster, but MarkLogic doesn't check for duplicates of the
URI in other forests. That's left to the application. The Hadoop connector sometimes uses this
advanced technique.
55