![[Contents]](FIGURE/CONTENT.GIF)
OpenTP1 Version 7 Description
![[Glossary]](FIGURE/GLOSS.GIF)
![[Index]](FIGURE/INDEX.GIF)
![[Back]](FIGURE/FRONT.GIF)
![[Next]](FIGURE/AFTER.GIF)
The XA resource service coordinates transactions between OpenTP1 and the following resource, using a two-phase commit:
The functionality that links OpenTP1 with a .NET Framework application is known as MSDTC linkage. MSDTC linkage enables transactions to be linked between an OpenTP1 resource and an MSDTC resource. To use MSDTC linkage, Y must be specified in the xar_msdtc_use operand in the XA resource service definition.
This section provides an outline of transaction control based on the XA resource service. For details about operation, see the description of the XA resource service in the manual OpenTP1 Operation. For details about trace information related to the XA resource service, see 5.3.6(5) XAR performance verification trace and 5.3.6(9) XAR event trace.
In this manual, where there is no functional difference between an application server running on J2EE and a .NET Framework application, the term application server linked by the XA resource service is used.
The main purpose of the XA resource service is to manage the status of transaction identifiers (XIDs) passed by an application server linked by the XA resource service, and to map them with OpenTP1's XIDs. When MSDTC linkage is used, the XA resource service also manages transaction recovery information (RI). RI is information created by MSDTC during transaction determination so that the transaction can be recovered if an error occurs in the processing. The transaction status is recorded in the OpenTP1 file system as required.
An application server that runs on J2EE controls transactions via the uCosminexus TP1 Connector or Cosminexus TP1 Connector, which complies with J2EE Connector Architecture. OpenTP1 receives transaction requests from the J2EE application server on a RAP-processing server, and processes transactions using the XA resource service.
Figure 3-8 shows the flow of transaction control when OpenTP1 is linked with an application server that runs on J2EE.
Figure 3-8 Transaction control when linked with a J2EE application server
![[Figure]](FIGURE/ZU030701.GIF)
A .NET Framework application uses MSDTC to control transactions, and sends instructions to OpenTP1 via Connector .NET. OpenTP1 receives transaction requests from the .NET Framework application on the RAP-processing server, and processes transactions using the XA resource service
Figure 3-9 shows the flow of transaction control when OpenTP1 is linked with a .NET Framework application.
Figure 3-9 Transaction control when linked with a .NET Framework application
![[Figure]](FIGURE/ZU030703.GIF)
Control of OpenTP1 transactions from a J2EE application server conforms to J2EE Connector Architecture. J2EE Connector Architecture is the standard specifications for connecting an application server and a resource adapter.
By conforming to J2EE Connector Architecture, the application server can control the OpenTP1 transactions in the same manner it handles a DBMS and other resource adapters. OpenTP1 can function as a standard resource adapter on different types of application servers.
There are two transaction control interfaces conforming to J2EE Connector Architecture:
For details about each interface, see the J2EE Connector Architecture documentation.
The XA resource service is used to accept transaction control using the XA resource interface on OpenTP1.
To use the XA resource service, you must use the remote API facility and the following products:
When linking with a .NET Framework application, we recommend that you specify 00000001 in the value attribute of the <extendLevel> element in the TP1/Client for .NET Framework configuration definition. By specifying 00000001, the IP address of the node requesting the transaction will be shown in message KFCA32045-E, which appears when transaction determination fails because the XAR file has insufficient record length.
The remote API facility is the process by which an API issued by the client side is forwarded by OpenTP1 to the server, and server processes are used to execute the API instead of the client. The server that executes API calls for the client is called the RAP-processing server.
The XA resource service runs on the RAP-processing server that uses the remote API facility. The RAP-processing server manages all transaction requests from an application server linked by the XA resource service. Therefore, to use the XA resource service, the RAP-processing server must be started beforehand. If the RAP-processing server is not running, all transaction requests from the application server linked by the XA resource service will result in an error.
OpenTP1 sets up a logical communication path called a permanent connection between the UAP that requests remote API calls and the RAP-processing server. There are two scheduling methods for the permanent connection: static connection schedule mode and dynamic connection schedule mode. The XA resource service can use either mode.
For details about the remote API facility, see 3.7 Remote API facility.
TP1/Client/J is a software product that acts as the intermediary when a transaction request is transferred from a J2EE application server to OpenTP1.
Client .NET is a software product that acts as the intermediary when a transaction request is transferred from a .NET Framework application to OpenTP1.
The XA resource service requires the remote API facility. For this reason, service requests by RPCs from TP1/Client/J or Client .NET must be implemented using the remote API facility. Also note that the available connect mode is limited to the auto connect mode when the remote API facility is used.
TP1/Client/J and Client .NET use four types of remote procedure service calls: Synchronous response, non-response, chained, and not inheriting transactions. The XA resource service can use any of the four.
In a normal RPC, multiple host names can be specified as OpenTP1 nodes receiving the transaction request. When using the XA resource service, however, only one OpenTP1 host name can be specified to receive the transaction request from the application server linked by the XA resource service.
Table 3-1 lists the TP1/Client/J or Client .NET functions that can be used with the XA resource service.
Table 3-1 List of TP1/Client/J or Client .NET functions supported by the XA resource service
| TP1/Client/J or Client .NET function | Existing option | Availability |
|---|---|---|
| RPC service request method | Remote API facility | Yes |
| Scheduler direct facility | No | |
| Name service facility | No | |
| Connect mode | Auto connect mode | Yes |
| Non-auto connect mode | No | |
| RPC service call type | Synchronous response | Yes |
| Non-response | Yes | |
| Chained | Yes | |
| Not inheriting transactions | Yes | |
| Specification of OpenTP1 host name as the receiver (specified in the dchost operand) | One name only | Yes |
| User data compression | Data compression | Yes |
For details about TP1/Client/J functions, see the manual OpenTP1 TP1/Client User's Guide TP1/Client/J.
For details about Client.NET functions, see the OpenTP1 TP1/Client for .NET Framework User's Guide.
uCosminexus TP1 Connector or Cosminexus TP1 Connector is a software product for controlling OpenTP1 communication and transactions, acting as a resource adapter compliant with J2EE Connector Architecture. An application server running on J2EE can instruct OpenTP1 to perform a two-phase commit by controlling transactions to uCosminexus TP1 Connector or Cosminexus TP1 Connector.
For precautions when linking OpenTP1 with a J2EE application server using the XA resource service, see the uCosminexus TP1 Connector or Cosminexus TP1 Connector documentation.
Connector .NET is a software product for controlling communication and transactions from a .NET Framework environment to OpenTP1. In MSDTC linkage, Connector .NET works as a resource manager participating in the MSDTC transaction. MSDTC can instruct OpenTP1 to perform a two-phase commit by controlling transactions to Connector .NET.
For precautions when linking OpenTP1 with a .NET Framework application using the XA resource service, see the OpenTP1 TP1/Connector for .NET Framework User's Guide.
Various timer monitoring facilities are available for canceling transaction processing when a request from an application server linked by the XA resource service stops, or when processing of a user application program is held up.
Figure 3-10 describes the range of timer monitoring facilities that apply to an application server linked by the XA resource service, an RAP-processing server, and an SPP.
Figure 3-10 Ranges of the timer monitoring facilities
![[Figure]](FIGURE/ZU030702.GIF)
Table 3-2 lists the types of monitoring performed, and the required operand, for timer monitoring periods t1 to t7 in the figure.
Table 3-2 Types of timer monitoring and applicable operand
| Period | Monitored item | J2EE application server# | .NET Framework application | OpenTP1 |
|---|---|---|---|---|
| t1 | Inquiry interval | TP1/Client/J environment definition: dccltinquiretime operand | TP1/Client for .NET Framework configuration definition: inquireTime attribute of the <rapService> element | RAP-processing listener service definition: rap_inquire_time operand |
| t2 | Message exchange | TP1/Client/J environment definition: dcwatchtim operand | TP1/Client for .NET Framework configuration definition: watchTime attribute of the <rpc> element | RAP-processing listener service definition, user service default definition, or system common definition: watch_time operand |
| t3 | Transaction branch processing | TP1/Client/J environment definition: dcclttrexptm operand | TP1/Client for .NET Framework configuration definition: expireTime attribute of the <xarTransaction> element | RAP-processing listener service definition, user service default definition, or transaction service definition: trn_expiration_time operand |
| t4 | Transaction branch in idle state | -- | -- | XA resource service definition: xar_session_time operand |
| t5 | Completion of transaction branch processing | -- | -- | RAP-processing listener service definition, user service default definition, or transaction service definition: trn_completion_limit_time operand |
| t6 | Transaction branch processing | -- | -- | User service definition, user service default definition, or transaction service definition: trn_expiration_time operand |
| Processing of a service function | -- | -- | User service definition, user service default definition: service_expiration_time operand | |
| t7 | Completion of transaction branch processing | -- | -- | User service definition, user service default definition, or transaction service definition: trn_completion_limit_time operand |
All Rights Reserved. Copyright (C) 2006, 2010, Hitachi, Ltd.