Interposed Servers

Until now, we did not consider, how a remote recoverable server is bound to the transaction management service. Again, there are two alternatives, namely interposed and non-interposed. With interposition, the xots installs a co-local implementation of transaction Coordinator and Control. Therefore, all calls for registration of recoverable objects (i.e. the respective Resource), as well as calls for transaction status or name inquiries are served by co-local objects. Thanks to TAO's smart proxies, interposition is transparent to the application. The smart proxies installed by xots have the same C++ language mapping as remote references for Coordinator and Control. In order to preserve checked transaction behavior and to guarantee, that the recoverable server participates in the 2PC, xots registers a subordinate (we name it interposed_2PC ) as Resource object with the remote Coordinator.
The remote Coordinator may reside in an interposed client or in the TXsvc. By only having one Resource at the interposed server that is remotely bound in the 2PC, we potentially save significant 2PC overhead. This setup is often referred to as two-level 2PC. From an implementation perspective, the interposed_2PC acts in the role of a (subordinate) Coordinator with respect to local Resources. Instead of deciding commit or abort, the interposed_2PC merely collects local votes and passes the preliminary decision on to the root Coordinator, which finally decides on the outcome of the transaction. The root Coordinator then forwards the commit/rollback call to all registered Resources, including any interposed_2PC. In turn, the latter passes the decision on to co-locally registered resources.