You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
At the point of the insert call, the request needs to acquire a write-lock. To get the lock,<br />
it issues a request to all forests to see if the document already exists. If so, that forest<br />
will obtain the write lock (and the new version of the document will be placed back<br />
into that forest). If the URI is new, the E-node picks a forest in which it will place the<br />
document, and that forest obtains a write lock. By default, the E-node picks the forest<br />
in a deterministic way based on how its URI maps to a set of abstract "buckets" (see<br />
the "Rebalancing" section for details) so as to ensure that any other concurrent requests<br />
look to the same D-node for the write lock. (Different ways of choosing a forest are also<br />
possible. See the "Rebalancing" and "Locking with Forest Placement" sections<br />
for details.)<br />
By obtaining locks during writes, MarkLogic ensures that updates are isolated.<br />
Transactions that want to update the same document must wait their turn. Locks also<br />
help ensure consistency. Without locks, transactions making simultaneous updates to the<br />
same documents could leave values in an inconsistent state.<br />
When the update request code completes successfully, the E-node starts the commit<br />
work. It parses and indexes the document and sends the compressed document to the<br />
D-node forest selected earlier. The D-node updates the in-memory stand, obtains a<br />
timestamp, journals the change on disk, and changes the timestamp of the document to<br />
make it live, then releases the write lock.<br />
The fact that MarkLogic writes the update to an on-disk journal before making the<br />
updated document live helps to ensure durability. If a system failure were to wipe out<br />
changes that had been made in memory, the data could be reconstituted by replaying<br />
what's in the journal.<br />
What happens with an insert or update that involves multiple documents? And what<br />
happens when that transaction crosses multiple forests in the same transaction?<br />
MarkLogic uses a classic two-phase commit between the D-nodes to ensure that the<br />
update either happens atomically or doesn't happen at all. See Figure 9 for details.<br />
54
Change language