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

A State Less Session Bean gets invoked within an XA transaction, and the business
logic of the bean needs it to invoke a legacy platform service in the form of a TS/MP
serverclass with the help of JPathsend API. In such a case, non-XA resource, like
the serverclass invocation is expected to take part in the global transaction and
hence, the resources accessed by the serverclass also become an integral part of
the global transaction.
Use Case 2: A session bean is the owner of an XA transaction
A session bean starts a transaction using the transaction manager provided by the
container and performs database operations using JDBC (T2 or T4) and invokes a
TS/MP serverclass using JPathsend. On successful completion of all the database
related operations, it adds a message to the JMS queue and then commits the
transaction. In such a case, the XA resources (JMS queue and JDBC T4) and the
non-XA resources (JDBC T2 and JPathsend) are expected to participate in the
transaction started by the session bean.
Use Case 3: Client application is the transaction coordinator
A client application (using the JTA libraries provided by NSASJ) begins a transaction
and invokes an EJB that performs database operations, and also invokes a TS/MP
serverclass which is also involved in database operations. Upon successful invocation
of the EJB, the client application can invoke a commit on the transaction that commits
the work performed. The work committed is not the one performed by EJB, but by
the TS/MP serverclass too. If rollback is invoked, then work performed by the EJB
and the TS/MP serverclass are both rolled back.
Recovery logs
This section explains in brief the need for recovery logs and the performance optimizations in
NSASJ.
Usage of recovery logs
A transaction manager needs to maintain transaction logs for all in-flight transactions. These logs
are required to recover from a failed transaction. The transaction manager creates an object store
for each XAResource that participates in the transaction. The object store is updated with the
transaction state. When the transaction completes (either commits or rolls back), the object store
is deleted. These object stores are created as OSS files.
The following example illustrates the use of recovery logs:
1. XARes-A.prepare() is successfully invoked.
2. XARes-B.prepare() is successfully invoked.
3. XARes-A.commit() is successfully invoked.
4. At this point the transaction manager crashes.
5. The recovery manager starts and checks the state of the transaction by looking at the recovery
logs for XARes-A and XARes-B. It finds that XARes-A is committed and XARes-B is prepared
to commit. Thus, it commits XARes-B.
Single branch optimization
If the transaction spans only one branch, then the transaction manager applies single branch
optimization and does not create the recovery logs. In case of NSASJ, as stated earlier, the XARM
always gets registered, and thus the transaction has at least one branch.
NOTE: The container considers any transactional resource that is used by the application within
a transaction context, and that are recognized by the transaction manager. These are obtained
by a JNDI lookup as a transaction branch.
70 Configuring NSASJ