CORBA 2.6 Programmer's Guide for Java
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 coupledthat 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 61 illustrates one way
that the problem can arise.
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
org.omg.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
System Administration Guide.
Chapter 6. Writing Scalable
Applications
Chapter 8. Writing Multithreaded
Applications