Transactions may be either local or distributed.
Local transactions are used on a single node even if they span multiple JVMs on the node.
Distributed transactions are used between TIBCO ActiveSpaces® Transactions nodes. When a transaction spans TIBCO ActiveSpaces® Transactions nodes a global transaction is started on the node that initiates the distributed work. The initiating node acts as the transaction coordinator. There is no independent transaction coordinator in TIBCO ActiveSpaces® Transactions . All TIBCO ActiveSpaces® Transactions nodes act as a transaction coordinator for distributed work that they initiate.
Nodes may be added to a distributed transaction not only by the node that initiated the distributed transaction, but by any node that participates in the distributed transaction.
Figure 5.2, “Distributed transaction node participants” shows
how nodes are added to a distributed transaction. In this diagram
Node 1 starts a local transaction,
LT1, and then initiates a global transaction,
GT, to Node 2. Node
2 starts a local transaction, LT2, on behalf
of the global transaction GT and then initiates work on
Node 3 in the same global transaction
GT. Node 3 initiates another local
transaction LT3, and then initiates work on
Node 4, which starts another local transaction,
LT4.
The response back from each of the nodes contains information on the
local transaction that was started on the node, and any other nodes that
started local transactions. This allows the initiating node, to determine
which nodes need to be committed when the global transaction is committed.
This is shown in the diagram in the commit processing on Node
1 - a commit is sent to all four nodes, even though
Node 1 only initiated a global transaction to
Node 2.
There is no programmatic difference between local and distributed transactions. TIBCO ActiveSpaces® Transactions initiates the appropriate transaction type transparently depending on whether local or remote objects are in the transaction. There is a difference in how deadlocks are detected. See the section called “Deadlock detection”.
Distributed transactions optionally have a prepare phase. A prepare phase provides a mechanism to integrate with external transactional resources. A failure in any of the prepare notifiers causes the transaction to rollback.
A prepare phase is used if there are any updates in a transaction, or transaction notifiers (see the section called “Transaction notifiers”) are installed for a transaction. The transaction notifiers can be installed on any node that is participating in a distributed transaction. If no updates are done in a transaction, or no transaction notifiers are installed, the prepare phase is skipped to optimize the performance of distributed transactions by eliminating the additional network I/O required with prepares.
Applications can optionally install transaction notifiers that are called during the prepare phase and when the transaction commits or rolls back. Transaction notifiers can be used to integrate with external systems - both transactional and non-transactional. Transaction notifiers are executed on the node on which they were installed. A distributed transaction may have transaction notifiers installed on multiple nodes by the application. In this case, the notifiers are executed on each node on which they were installed.
