Appendix B. Transaction Resource Management

Managing Failed Transaction Retries and Ispec Resource Consumption

Agile Business Suite Runtime for ClearPath MCP allows the user to define a custom global failed online transaction retries value. It is also possible for the user to manage Ispec resource consumption and Ispec specific failed transaction retries values using Ispec specific properties.

The relevant properties are stored in a file under the usercode of the application. This file is called

(<app usercode>)<system name>/CONSTRAINTS/CONFIG ON <dictionary pack>

Valid properties are:

[GLOBAL]
RETRIES, <n>
WAIT, <wait time>

[ISPECS]
<ispec>,<retries>,<max DB reads>,<max DB writes>,<max elapsed secs>,<max cpu secs>
<ispec2>,<retries>,<max DB reads>,<max DB writes>,<max elapsed secs>,<max cpu secs>

...

<ispecN>,<retries>,<max DB reads>,<max DB writes>,<max elapsed secs>,<max cpu secs>

The description of these properties are described later in the section.

When it is present, the CONSTRAINTS/CONFIG file is loaded at system startup. While the system is active, the CONSTRAINTS/CONFIG file may be reloaded by

All the active constraints may be disabled by

This will disable all active Ispec resource constraints and revert the RETRIES value to the default value (2).

The responses may be viewed from MARC/ODT/Sumlog.

Global Failed Transaction Retries

RETRIES, <n>

<n> indicates the global default failed transaction retries value. Valid values for n are 0 to 3.

0 – Failed transactions will not be retried

1 – Failed transactions will be retried once

2 – Failed transactions will be retried 2 times

3 – Failed transactions will be retried 3 times

The system default value is 2.

Wait Cycle Time for Transaction Checks

WAIT, <wait time>

<wait time> specifies the time interval between transaction checks. Enter the time, in seconds, up to 2 decimal places. For example,

WAIT, 2.56

The range of valid values is 0.5 to 120.

Within the life of a transaction, a comparison between resource constraints and actual resource consumption is made. These comparisons or checks may be done frequently or infrequently. <wait time> is used to specify how much time elapses between checks.

Ispec Resource Consumption

<ispec>,&lt;retries>,<max DB reads>,<max DB writes>,<max elapsed secs>,<max cpu secs>

For any Ispec, include these properties to define values for the following Ispec related properties:

If you do not wish to specify a limit for one or more of the properties, enter 0 for the corresponding parameter.

These resource constraint values will be compared by the runtime infrastructure to the Ispec’s actual transaction resource consumption regularly and appropriate action will be taken when one or more of these values is exceeded. To clarify, the user defined resource constraint values are compared to actual resource consumption values from a single transaction, they are not compared to an accumulation of resource consumption values across multiple transactions. More details about comparison of constraint values and actual resource consumption is available later in this section.

Using the Global Properties

Use the RETRIES parameter to define the number of retry attempts before aborting the failed transaction.

Use the WAIT parameter to define how frequently to check the resource consumption for the active transaction.

Specify the Ispecs that are to be monitored.

For example,

[GLOBAL]
RETRIES, 2	
WAIT, 2.56

[ISPECS]
PROD,2,0,0,0,0
CUST,1,0,0,0,0

For this case, the runtime infrastructure will check the resource consumption of any of the defined Ispecs (PROD and CUST) every 2.56 seconds, if they are executing. The WAIT value should be tailored towards the minimum of any defined elapsed (<max elapsed secs>) or CPU time constraint (<max cpu secs>) (except 0). In an ideal situation, the WAIT value should not exceed this minimum value, to improve the accuracy of the monitoring. The minimum value for WAIT of .05 seconds and the maximum value is 120 seconds.

Using the Ispec Properties

The management of specific Ispec properties (with the exception of Retries) requires the presence of interrupt methods, which are owned by the Ispec. The interrupt methods are invoked by the runtime infrastructure when any of the defined resource values are exceeded (For example, maximum database reads, maximum cpu time). The onus is on the user to create them when they are needed.

There are four possible interrupt methods for an Ispec.

The first three interrupt methods are associated with the Ispec cycle method indicated by their name.

The INT_DEFAULT interrupt method is defined when the user does not want to define interrupt methods specifically for one or more of the cycle logic methods and wants to define a generic interrupt method.

If all four interrupt methods are defined, an entry in the Build log will note that the INT__DEFAULT method is ignored, as there are specific interrupt methods defined for all cycle logic methods.

Each of the interrupt methods must be defined with no parameters and no return value. If an interrupt method is created with parameters or a return value, that method will be treated as a normal Ispec method and will not be used as an interrupt method (a generate log warning will be issued for the method).

The interrupt methods are intended to be used by the runtime infrastructure only, and only invoked when they are needed. While there is nothing to prevent user LDL+ logic invoking these methods directly, avoid doing this, the results may be unpredictable.

The interrupt methods themselves may invoke any LDL+ commands including ABORT.

During the deployment of the system, the build processing will update or create the <system name>/CONSTRAINTS/CONFIG file with the details of any Ispec possessing atleast one INT__.. method.

For a file created by the generate process the comments (% in column 1) detailing the record format are also included.

If an Ispec entry is already present in the file, it is skipped as it may have been updated by the user. The Ispec entries that are created in this file by the build processing are added with a default Ispec failure retries value of 2 and no constraints for the other resource values (a zero or missing value, except for <retries>, means no resource constraint).

An example of a CONSTRAINTS/CONFIG file created by the build process -

[GLOBAL]
%Specify Default Failed Transaction Retries	
RETRIES, 2	
%Specify Transaction Checking Wait Cycle Time	                                                       
WAIT, 2.56	
[ISPECS]
%<ispec>,<retries>,<max DB reads>,<max DB writes>,<max elap secs>,<max cpu 
secs>
PROD,2,0,0,0,0

The user may edit the file to update their Ispec specific resource constraint values. Where there is no constraint for a resource, then enter an explicit 0 or leave the remainder blank if no subsequent constraint values are applicable.

For example,

[GLOBAL]
%Specify Default Failed Transaction Retries	
RETRIES, 2	
%Specify Transaction Checking Wait Cycle Time	                                                       
WAIT, 2.56	
[ISPECS]
%<ispec>,<retries>,<max DB reads>,<max DB writes>,<max elap secs>,<max cpu 
secs>
PROD,2,100,0,5.8,2.95
CUST,1,150, 200

From the above, PROD Ispec has a Retries value of 2 and will be monitored for the maximum resource constraints of 100 database reads, 5.8 seconds elapsed time and 2.95 seconds CPU time. There is no constraint for the maximum database writes.

From the above, CUST ispec has a Retries value of 1 and will be monitored for the maximum resource constraints of 150 database reads and 200 database reads. No other constraints have been applied.

Both <max elap secs> and <max cpu secs> may be entered with up to 2 decimals.