Introduction and xots Overview For first-time CORBA Object Transaction (OTS) users, the following link may be worth reading: TP Nuts and Bolts by Dr. Subrahmanyam Allamaraju. If you are familiar with transaction semantics and systems, read on for a review of OTS concepts and a brief presentation of xots design rationals: OTS Concepts The Object Transaction Service (OTS) implements the two-phase commit protocol in a CORBA environment. Its model can be viewed as an object-oriented extension of the X/Open DTP model. The spec reads, that OTS provides ACID guarantees for CORBA object interactions. ACID stands for Atomicity, Consistency, Isolation and Durability. We should be a little more clear on that point: traditional transaction processing systems, databases in particular, provide Atomicity, Isolation and Durability guarantees by putting everything under control of the DBMS (or TP monitor). Notice, that Consistency is for a great deal an application responsibility, anyway. In order to provide A(C)ID, the DBMS will manage the transaction, set and release locks for accessing data, manage a data buffer and carefully write log records. Some buzzwords that are relevant in this context are "two-phase locking", "shadow-copies", "deferred update", "update-in-place", "write-ahead-logging", "ARIES" ( need more ?). Even, if you are not an expert in the field, you can see, that none of the before mentioned buzzwords are directly involved in OTS (and in X/Open DTP either). It is one of the goals to achieve ACID interactions in distributed object settings by using an Object Transaction Service. That is, the OTS itself merely provides a transaction coordination framework, not simply a service you call. The OTS keeps track of transaction contexts and ships transaction contexts with invocations on CORBA objects. The OTS lets you register Resource objects. Those resources implement and receive the two-phase-commit (2PC) callbacks, once registered with a transaction. The OTS will drive the 2PC and is responsible for reliably logging transaction outcome for recovery purposes. In concert with so called resource managers, like databases and queues, you may assert ACID properties for your application data. If your recoverable objects set and hold locks until end of transaction, assure the ability to undo changes in case of failure and follow the 2PC rules, you are on the right way for realizing atomic transactions. This is what you get, when you are integrating typical resource mangers such as XA compliant databases or queues in your application. Before following this direction, make sure, that this is really the semantics required by your application. Carefully consider the impact of (exclusively) locking resources for the duration of a transaction and make sure that you can afford those with respect to scalability and performance requirements. You may want to take a look at what is called "advanced transaction models", like open-nested transactions, nested SAGAs, BPT, and some more relaxed isolation models, e.g. snapshot isolation, multi-version serializability and others.