CORBA 2.6.1 Programmer's Guide for C++

at termination. This means that all other threads must have suspended and that any references to Control, Coordinator, and Terminator object
implementations 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.
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 Transaction Service components of NonStop CORBA throw the exception
BAD_INV_ORDER.
Transaction Branches and the Diamond Access Problem
Because of the way TMF handles distributed transactions, you may need to design your application to avoid database access deadlocks
between transaction branches, sometimes called the diamond access problem. This problem is not specific to NonStop CORBA, and can
occur in any system where TMF is used. It is most likely to occur in highly distributed applications with distributed databases.
Each import and export of a transaction to a different process creates a new transaction branch. In the TMF environment these branches are
loosely coupled—that is, the work of two transaction branches is not recognized as being part of the same transaction. Therefore, two
transaction branches attempting to lock the same SQL data may encounter SQL errors or deadlocks.
The diamond access problem occurs when an application begins a transaction on one system and subsequently invokes multiple transactional
objects on multiple systems.
Figure 6–1 illustrates one way that the problem can arise.
Figure 7.1. Diamond Access Problem
In this figure, the application starts a debit/credit transaction on System A. The debit account is held on System B and the credit account is held
on System C. System D has an object that requires input from both debits and credits (in this case a Bank Vault Account that tracks debits and
credits). The problem occurs when Systems B and C attempt to write to the Bank Vault object on System D. At that time, one write operation
might be locked out by the other. The transaction monitor at that point doesn't know to end or cancel the transaction, because it doesn't see the
interactions between B, C, and D. D doesn't know that both attempts to write to it belong to one transaction.
You can avoid diamond access by changing the distribution of the application across systems. For example, if Systems B and C were the same
system, the problem would be avoided.
Another solution is to set a timeout for the transactions in these complex situations, using the
CosTransactions::Current::set_timeout()
operation. Although the problem can still occur, the blocking transaction times out after the specified interval, and the block is then lifted.
In configurations where the NSotsTM process runs as a server pool with multiple processes, contention between NSotsTM processes can cause
the diamond access problem to occur. To avoid this cause of the problem, no application changes are required. NonStop CORBA provides the
NSotsXID process to act as a broker between NSotsTM processes, so that only one process has control at a time. When you configure the
NSotsTM process as a server pool with multiple processes, all you need to do is to configure a singleton NSotsXID process. For further
information, refer to the NonStop CORBA 2.6.1 Administration Guide.