HP Integrity NonStop H-Series - Manual (Page 71)

Non XA resources in a transaction
The default behavior of the transaction manager requires all transactional resources to participate
in 2pc protocol. This restriction is relaxed for at most one branch, which, means of all the transaction
branches, only one branch can select not to participate in 2pc protocol. This branch gets committed
first after all the branches are prepared for commit. If the transaction manager relaxes its requirement
for more than one resource, then it can leave the transaction in an unstable state.
Table 21 (page
71) provides an example for the same.
Table 21 Non XA resources in a transaction
Outcome Operation Resource
Success prepare XARes-A
Success prepare XARes-B
Success commit Non-XARes-A
Failure commit Non-XARes-B
The scenario in Table 21 (page 71) depicts that if the commit on non-XA-Res-B fails, then there
is no way the commit operation on non-XA-Res-A be undone. The container considers normal
JDBC connection that participated in a transaction as non-XA Resources. JDBC XAConnections
are considered as XA resources.
NonStop resources in a transaction
Practically, a transaction (in NSASJ) rarely has only one branch and hence, the transaction manager
does not apply single resource optimization.
NOTE: As already stated the XARM (which is an XAResource) gets registered with the transaction
manager, and hence, there is always one branch.
When all the transactional resources (such as SQL/MX) that participate in a transaction are
controlled by TMF, creating an object store for the XARM is undesirable. This is because the purpose
and scenario for which the object store is created does not occur, and moreover creating an object
store has significant performance overheads. This is explained with the help of the following
examples:
1. Application performs database operations using JDBC SQL/MX T2 driver
In this example, although the transaction contains two branches, a successful commit operation
of the XARM results in the database operations also getting committed. In actual, the transaction
branch involving the T2 driver remains a dummy participant.
2. Application does database operations using JDBC SQL/MX T4 driver
In this example, the T4 driver can be configured to use an external TMF transaction rather
than creating its own. In this case too, all the database operations done by the T4 driver
comes within the scope of the transaction initiated by XARM. Thus, committing the transaction
branch of the XARM essentially commits all the work performed by the T4 driver too.
3. Application performs database operations and then uses JToolkit API to perform Enscribe and
Pathsend operations
For the container there are two branches in which, one is with XARM and the other with JDBC.
The operations performed by using JToolkit are not considered as a transaction branch because
transaction manager does not recognize JToolkit as a resource.
Performance enhancements for XARM
NSASJ provides a feature that prevents the creation of the recovery log, thereby saving a lot of
time that is generally lost in file operations. To prevent the transaction manager from creating a
Transaction management 71