CORBA 2.6.1 Programmer's Reference

resource is still required to wait for Resource::commit() or Resource::rollback() to be
invoked. The RecoveryCoordinator will only be used by very sophisticated server applications.
TransactionalObject Interface (2.11)
The specification says that an object that supports the TransactionalObject indicates that it wants
the transactional context associated with the client thread to be associated with all operations on its
interface. In creating a transactional object it might be tempting to inherit from a non-transactional base
object and TransactionalObject. This would allow both transactional and non-transactional
instances to be invoked through a base interface class object reference. This will not work because the
base interface proxy stub will not be able to determine that a derived instance also derived from
TransactionalObject and therefore the ORB will not implicitly propagate the transaction context.
The User's View: Application Programming Models
(2.13.1)
The specification permits an implementation to employ implicit (OTS-provided) or explicit (by
parameter) transaction propagation. Explicit propagation is not supported by Nsots. Explicit propagation
can produce undefined results including breaking the transaction's ACID properties.
The User's View: Checked Transaction Behavior
(2.13.3)
The specification allows varying degrees of semantic checking. This is called checked execution.
NSOTS tries to enforce the rule that only one thread can remain active in a transaction at termination.
This means that all other threads must have suspended and that any references to Controls,
Coordinators, and Terminators must have been released. Without these checks, some
application work might not actually complete within the transaction's boundaries or a memory leak of
object references might go undetected. The exception BAD_INV_ORDER is thrown if an attempt is made
to terminate a transaction when its reference count indicates that another thread may potentially be
working on the transaction.
The User's View: Resume Check (2.13.4.3)
Resume checking is weak in NSOTS. Poorly designed code can produce undefined results including
breaking the ACID properties. See discussion of explicit propagation in The User's View: Application
Programming Models, above.