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

NSASJ Server and TMF
NSASJ Server integrates with TMF to provide unified standards based transaction interface in the
form of JTA. The subsequent subsection first explains the internals of the JTA implementation and
then explains how it integrates with TMF.
JBoss AS ships with an inbuilt Transaction Manager. The Transaction Manager is infact an
independent JBoss product by name Narayana (alias JBoss TS). NonStop provides a product by
name XARM which is a Resouce Manager for TMF. The interface that defines the interactions
between a Resource Manager and Transaction Manager is
javax.transaction.xa.XAResource
. XARM provides a complete implementation of the
XAResource interface.
NSASJ internally modifies the Transaction Manager to register XARM as a resource manager for
all transactions.
NSASJ and Resource Managers in TMF
Every instance of NSASJ registers the XARM only once in entire process lifecycle. At the time of
instantiating the XARM library a Resource Manager gets registered with TMF. The name of the
Resource Manager is of the format NSXARM. The Resource Manager goes into a CLOSED
state once the server instance that created it is stopped. These Resource Managers remain orphaned
and have to be manually deleted.
Configuring the limits
The XARM library has to be instantiated with certain limits. These limits can be configured in the
xarm.properties
file located in $NASASJ_HOME/modules/com/hp/nsk/xares/wrapper/
main .
•
maxtrans : This parameter indicates the maximum number of concurrent TMF transactions
that the library can handle. The default value is 100. The value of this parameter must never
be less than the maximum number of concurrent requests (MAXLINKS) each instance is
configured to handle.
•
maxthreads : This parameter indicates the size of the data structure internal to the XARM
library that holds the state of threads that have a transaction context associated with it. In
NSASJ the value of this must be the same as that of maxtrans parameter.
NSASJ and JDBC
The following discussion relates to JDBC usage in NSASJ:
Connection Pooling and Statement Caching
Applications performing database operations rely on pooled JDBC connections and cached
statements. While the SQLMX JDBC driver (both T4 and T2) provides both these features, the
container too provides infrastructure to pool connections and cache statements. The container
provides this as part of its JCA infrastructure and can be configured in the datasources
configuration either globally in domain.xml file or in the application specific *-ds.xml files.
The container provided datasources can be monitored using the management UI (both GUI based
and CLI based) when configured in domain.xml. Currently, there is no infrastructure in NSASJ
to monitor the operations of the driver.
TMF transactions and JDBC
It is important to understand some TMF related features offered by the JDBC drivers in context of
NSASJ. The following discussion assumes that the EJB invocation is within an XA transaction context
(and hence within a TMF transaction context initiated and controlled by XARM):
T4 driver
SQLMX JDBC T4 driver provides features to perform database operations as part of a TMF
transaction context external to the JDBC driver. This can be controlled by the connection attribute
NSASJ Server internals 97