Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
a document like this, but the statement also adds the new fragment ID to its personal<br />
"added" list. This overrules the timestamps view. When a later statement in the same<br />
transaction looks at the database, it knows the fragments in the "added" list should<br />
be visible even if they're nascent. It's the same for deletion. When a statement in a<br />
multi-statement transaction deletes a document, the deletion timestamp isn't updated<br />
right away, but it gets added to the "deleted" list. These fragments are hidden from the<br />
transaction context even if the timestamp data says otherwise. What about document<br />
modification? With MVCC, that's the same as a combination delete/add. The logic<br />
is actually pretty simple: if a fragment is in the "deleted" list, then it's not visible; else<br />
if it's in the "added" list, then it is visible; else just follow the usual creation/deletion<br />
timestamp data for the fragment. 10<br />
Multi-statement transactions make deadlock handling a little more interesting. With<br />
single-statement, auto-commit transactions, the server can usually retry the statement<br />
automatically because it has the entire transaction available at the point of detection.<br />
However, the statements in a multi-statement transaction from a Java client may<br />
be interleaved with arbitrary application-specific code of which MarkLogic has no<br />
knowledge. In such cases, instead of automatically retrying, MarkLogic throws a<br />
RetryableXQueryException. The calling application is then responsible for retrying<br />
all of the requests in the transaction up to that point.<br />
Should any server participating in the multi-statement transaction have to restart during<br />
the transaction, it's automatically rolled back.<br />
XA TRANSACTIONS<br />
An XA transaction is a special kind of multi-statement transaction involving multiple<br />
systems. XA stands for "eXtended Architecture" and is a standard from The Open<br />
Group for executing a "global transaction" that involves more than one back-end<br />
system. MarkLogic supports XA transactions, enabling transaction boundaries to cross<br />
between multiple MarkLogic databases or between MarkLogic databases and thirdparty<br />
databases.<br />
MarkLogic implements XA through the Java JTA (Java Transaction API) specification.<br />
At a technical level, MarkLogic provides an open source XAResource that plugs<br />
into a JTA Transaction Manager (TM) and handles the MarkLogic-specific part<br />
of the XA process. The Transaction Manager (provided by your Java EE vendor,<br />
not by MarkLogic) runs a typical two-phase commit process. The TM instructs all<br />
participating databases to prepare to commit. Each participant responds with whether<br />
or not it is ready to commit. If all participants are prepared to commit, the TM<br />
instructs them to commit. If one or more participants are not prepared to commit, the<br />
TM instructs all participants to roll back. It's the point of view of the TM that decides<br />
10 Multi-statement transactions were introduced in MarkLogic 6, but this is not new code. MarkLogic has<br />
had post-commit triggers for years that use the same system.<br />
44
Change language