The following figure shows the operation of the XA resource service.

Figure 3-29 Operation of the XA resource service

When using the XA resource service, invalid transactions may remain in the following circumstances:

• A RAP-processing listener or a RAP-processing server was forcibly terminated (using the command dcsvstop -f)
• In this case, start a RAP-processing listener or a RAP-processing server (using the command dcsvstart).
• An operation was performed which is not guaranteed by the remote API facility
• The definition of an active RAP-processing listener and RAP-processing server was changed by the rapdfgen command before the RAP-processing listener and the RAP-processing server ended normally.
  In this case, the operation is not guaranteed.
  

The following table shows how transaction information is managed when linked with an application server based on J2EE architecture.

Table 3-31 Transaction information management (when linked with a J2EE application server)

Transaction request type	Transaction information management			Change in transaction status (Normal)
	Start	End	File I/O
Start()	Y	N	Y	None -> Active
Call()	N	N	N	No change
End()	N	N	N	Active -> Idle
Prepare()	N	N	N	Idle -> Prepared#1
		Y	N	Idle -> None#2
Commit()	N	Y	N	Prepared -> None#3
				Idle -> None#4
Rollback()	N	Y	N	Prepared -> None#3
				Idle -> None#4
Recover()	N	N	N	No change
Forget()	N	Y	N	Heuristically Completed -> None

Legend:

Y: Executes processing

N: Does not execute processing

#1

When the transaction branch is read only.

#2

For two-phase commit or rollback.

#3

For one-phase commit or rollback.

The following table shows how transaction information is managed when linked with a .NET Framework application.

Table 3-32 Transaction information management (when linked with a .NET Framework application)

Transaction request type	Transaction information management			Change in transaction status (Normal)
	Start	End	File I/O
Call()	Y	N	N	None -> Active#1
	N	N	N	No change
Prepare()	N	N	Y	Active -> Idle -> Prepared
		Y	Y	Active -> Idle -> None#2
Commit()	N	Y	N	Prepared -> None#3
				Active -> Idle -> None#4
Rollback()	N	Y	N	Prepared -> None#3
				Active -> Idle -> None#4
Recover()	N	N	N	No change
Forget()	N	Y	N	Heuristically Completed -> None

Legend:

Y: Executes processing.

N: Does not execute processing.

#1

For the first Call() request of the transaction.

#2

When the transaction branch is read only.

#3

For two-phase commit or rollback.

#4

For one-phase commit or rollback.

The XA resource service can save transaction information to an XAR file when necessary.

(a) Creating XAR files

Create XAR files using the xarinit command, and delete them using the xarrm command. Check file information for an XAR file using the xarfills command.

Two types of XAR files are required: online XAR files and backup XAR files. Both files must have the same record length and number of records, and be accessible for file I/O operations.

An online XAR file is used in normal operation, but the backup XAR file is automatically swapped in if the normal XAR file is damaged. You should store the online XAR file and the backup XAR file on different disk volumes.

An XAR file uses one record for each transaction branch. Thus, the number of records in an XAR file must be equal to or greater than the maximum number of simultaneous transaction branches (the value specified in the trn_tran_process_count operand in the transaction service definition).

• When linked with a J2EE application server
  Each unit of record information in an XAR file occupies 512 bytes. When you use character-type special files, I/O operations on the file are performed in units of the sector length you defined in the -s option of the filmkfs command when you created the OpenTP1 file system. We therefore recommend that you specify a sector length of 512 bytes for the OpenTP1 file system. Note that with some OSs, the minimum sector length is greater than 512 bytes (with HP-UX, it is 1024 bytes). We recommend that you use the minimum sector length allowed by the OS. Specify a sector length that is a multiple of 512 bytes. If you are using the UNIX file system, file I/O operations are performed in 512-byte units by default.
  
• When linked with a .NET Framework application
  Because the size of the transaction recovery information (RI) depends on the environment where MSDTC is operating, in some environments the record length specified for XAR files may be inadequate to store the information. For this reason, when using the MSDTC linkage facility, we recommend that you specify a record length of at least 1024 bytes for XAR files to avoid problems with transaction determination.
  When defining the record length for XAR files (by executing the xarinit command with the -s option specified), specify a multiple of the sector length of the OpenTP1 file system. You can use the xarfills or xarls commands to find out the maximum size of RI data that XAR files can store.
  If transaction determination fails due to the record length for XAR files being too short, recreate the XAR files as follows:
  
  1. Shut down OpenTP1.
  2. Recreate the XAR files by executing the xarinit command, specifying the -s option as the value output as the required length of XAR files in the message KFCA32045-E.
  3. Start OpenTP1 in the normal manner.

(b) Specifying XAR files

Use the xarfile command in the XA resource service definition to specify the XAR files. You must have already created an XAR file that satisfies the above conditions. If you specify an XAR file that does not exist, an error results. An error also results if you specify an XAR file that contains fewer records than the value specified in the trn_tran_process_count operant in the transaction service definition.

Use the xarfile definition command with the -t online option to specify the online XAR file and the -t backup option to specify the backup XAR file. Make sure you specify both.

(c) Notes

OpenTP1 does not support XAR file duplication. Also, the XA resource service cannot manage transaction information in any of the following circumstances:

• OpenTP1 has not been started.
• The remote API facility has not been started.
• The XA resource service has not been started.
• The XA resource service has shut down.

The XA resource service shuts down whenever an error occurs in both the online XAR file and the backup XAR file. To release the XA resource service from shutdown status, execute the xarrles command. For details, see 3.14.4 Action to take if an error occurs in the XAR file.

To display the status of the transactions being managed by the XA resource service, use the xarls command. Execute the xarforce command to complete any undecided transactions.