A prepared transaction is one where, during the completion stage of a distributed transaction, all participating resource managers have acknowledged a successful prepare phase (phase I) of a two-phase commit process. Once a transaction has reached prepared state it awaits direction from the coordinating transaction manager about what is to be done at phase II.
The time between phase I and phase II is usually very short depending
upon how many resource managers must be coordinated together. For an Adabas
RM during this period, all necessary transaction
resources are retained and, until transaction completion occurs, such resources
are not subject to the normal Adabas timeout rules associated with transactions
and non-activity.
For various reasons, prepared transactions may occasionally not complete in a timely manner which may give rise to symptoms such as:
RSP145s due to ISNs on hold for extended periods;
Users waiting for ISNs on hold (wait on hold logic is used);
An increase in Adabas RM high water marks for User queue and Hold queue.
The most important thing in troubleshooting these situations is to give preference to understanding the problem from the perspective of Adabas Transaction Manager, do not use the perspective of one Adabas RM alone. The reason is obvious, Adabas Transaction Manager must coordinate many Adabas RM so it is the transaction manager that has all the information needed, not Adabas.
Use the Adabas Transaction Manager online administration tool to list all active transactions. In this list, prepared transactions have a status of PREPARED. Display the detailed transaction information and note the 28-byte communication ID and the list of changed databases. Check the presence of any response codes alongside these participating databases – a non-zero value may indicate a reason why completion has not taken place yet.
If a RSP145 has been reported it is likely application error routines have already identified the database number, file number and ISN in question, in which case it is a simple determine if the reported database matches any of those in the changed database list. Alternatively if users report waiting on ISNs then, for each of these changed databases, use Adabas online services command queue display to determine if any commands have a status of ‘waiting for ISN’, this enables rapid identification of any participating databases against which users are waiting for ISNs.
At this point you have identified one or more prepared transactions whose changed database list includes the database against which reports of RSP145s and waiting users have been made. For each of these transactions extract the TID from the 28-byte communication ID noted down earlier (last 8 bytes) and use Adabas online services hold queue display to identify the individual ISNs held by that TID. Match these file numbers and ISNs with the reported file number and ISN to identify the individual transaction responsible.
If this prepared transaction continues to remain incomplete then it may be necessary to attempt manual intervention to complete it. Refer to the section Stop Transaction in the Online Services documentation for information on how to do this.
If manual intervention does not result in the release of Adabas held resources, then the Adabas nucleus hosting these resources may be shut down in one of two ways:
Issue ADAEND and set
TT=1: This causes Adabas to perform heuristic commits of
any prepared transactions. A delay in shutdown of approximately 60 seconds is
expected;
Issue HALT: This causes Adabas to perform
heuristic backouts of any prepared transactions.
For additional information see Heuristic completion of prepared transactions.
Caution:
Either of these actions will heuristically complete the transaction
and as a result distributed transaction integrity is likely to be
lost.
