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.