XOTS Design and Implications for App Design

The OTS spec does not say, how the transaction services should be realized in much detail.
There is some flexibility in deploying an OTS:

• as library, linked with applications that make use of OTS
• as separate central service daemon
• as separate fully distributed service daemons (e.g. a svc daemon on each machine involved in a transaction).
• as hybrid combinations of the above approaches

xots follows the hybrid approach. The application must link against our xots library.
Transaction creation and coordination can be interposed to the application, i.e. the calls to OTS interfaces like Current/TransactionFactory/Coordinator are co-local calls to the xots implementation in the same process and address space - brought in by the xots library.
Contrast that approach to making calls to a centralized OTS service daemon.
Each operation like transaction creation, resource registration, 2PC callbacks, status or even simple tx name inquiries impose latency and throughput limitations by the remote service access.
And this performance penalty really hits hard. Be assured, that we will come up with some numbers showing the difference.
However, there is a drawback to having the whole service running in the app process, as well.
First of all, the recovery issue. Notice, that coordination of 2PC includes the responsibility to drive recovery in case of system failure. But what if the client app including the coordinator crashes ? Without any fail-over/replication techniques, the whole recovery process is blocked until the client comes up again. Blocking critical databases or message queues and thus tightly coupling their accessibility to the client is not really a good idea for most systems. Therefore xots has a recovery module that incorporates a RecoveryCoordinator in a separate daemon. Again, this daemon may run on each machine, or on some dedicated machines.
The second issue in a pure library approach is related to 2PC coordination. Packaging the complete OTS functionality in a library requires, that each application that starts a transaction also runs the Coordinator object. Additionally, 2PC coordination requires access and management of a stable (and high-performance) log. However, this is not always a feasible approach. Therefore xots provides "non-interposed transactional clients", which will be discussed in the next section.

As a first summary, we state that the overall architecture of an object transaction processing application must be designed very carefully - and there are some pitfalls you are likely to run in, if you think that OTS is just another service like Naming or InterfaceRepository. Not only is performance and the overhead introduced by using a transaction service important, but you have to take the dependability of your system into account, as well. The latter requires to decide, if and which functionality of xots should be interposed with the application code or run as a separate service. Further you have to consider on which machines those separate services (like recovery and 2PC coordination) are to be deployed.