By default, transactions are subject to time limits imposed at the infrastructure level (at a network or database level). In most cases, sites do not impose any explicit time limits.
The idea of time limits on transactions is to catch any long running online or web service transaction from causing inefficiencies in traffic volumes across your configuration. To use time limits effectively, the site would want to set limits on a number of key common transactions to keep a cap on resource usage across the enterprise.
In Oracle Utilities Application Framework V2.2 and V4.1 (and above), a set of configuration settings has been added to allow sites to specify global time limits and transaction level time limits on individual calls within a transaction. These changes are available via patches 11901962 (V2.2) and 10356853 (V4.1) available from My Oracle Support. For Oracle Utilities Application Framework V4.1, this patch was included in Group Fix 2.
The concepts of timeouts contained in the product are as follows:
Timeouts may be set globally or overridden on individual services, business objects, business services or service scripts.
Timeouts are tracked throughout the transaction execution but the timeout is explicitly checked prior to any database access to ensure the timeout has not been reached. If the transaction has multiple database access statements, the current cumulative transaction time is checked at each statement. If no database access is made by the transaction then timeouts are not checked and therefore not enforced.
Timeouts tolerances are taken from the parent object. For example, if a service script calls business objects and/or business services then the time allocated to the service script applies across all the calls not the timeouts of the individual business objects and/or business services.
The timeout values only apply to online transaction and web services calls (via XAI), therefore batch transactions are not subject to using this timeout facility.
When a timeout limit is exceeded, an appropriate error message is returned and the transaction is rolled back to the last commit or savepoint.
Timeout values are not precise. The transaction will not be terminated at the exact timeout value. When timeouts occur, additional processing time for transaction rollback and networking (such as load balancing) may need to be executed, which is performed after the timeout occurs, before returning control back to the originating user.
Most of the transactions in the product are subject to one timeout. If the transaction is part of a portal with multiple transactions, each individual zone is subject to its own timeout. If timeouts are not consistent across a portal then some zones may be timed out whilst others continue processing.
Configuration of Timeouts
Parameters that control timeouts are as follows:
ouaf.timeout.business_object.<bocode> - Maximum amount of time (in seconds) for business object <bocode> can execute before timeout. This timeout will override ouaf.timeout.business_object.default when executing this specific business object. The values for <bocode> may be any valid business object.
ouaf.timeout.business_object.default - Maximum amount of time (in seconds) an invokeBO call can execute before timeout. All queries issues by the business object will have life time remaining time of execution of this business object call.
ouaf.timeout.business_service.<bscode> - Maximum amount of time (in seconds) for business service <bscode> can execute before timeout. This timeout will override ouaf.timeout.business_service.default when executing this specific business service. The values for <bscode> may be any valid application service.
ouaf.timeout.business_service.default - Maximum amount of time (in seconds) an invokeBS call can execute before timeout. All queries issues by the business service will have life time remaining time of execution of this business service call.
ouaf.timeout.query.default - Maximum amount of time(in seconds) an individual query can run if it is not restricted by a service or some other timeout. For instance, if the online application is issuing a query, which is not a part of a service call, a script or a Business Object read, the query will be affected by this timeout. Otherwise, the timeout will be set to remaining time of a logical transaction it belongs to (service call, script, Business Object execution).
ouaf.timeout.script.<scriptname> - Maximum amount of time (in seconds) for script <scriptname> can execute before timeout. This timeout will override ouaf.timeout.script.default when executing this specific service script. The values for <scriptname> may be any valid application service script.
ouaf.timeout.script.default - Maximum amount of time (in seconds) all scripts, unless overriden, can execute before timeout. All queries issues by the script will have life time remaining time of execution of this script call.
ouaf.timeout.service.<service> - Maximum amount of time (in seconds) for service <service> can execute before timeout. This timeout will override ouaf.timeout.service.default when executing this specific service. The values for <service> may be any valid application service.
ouaf.timeout.service.default - Maximum amount of time (in seconds) all service, unless overridden, can execute before timeout. All queries issues by the service will have life time remaining time of execution of this service call.
For example, in general:
For example, to specify values for logical transactions that can be overridden with values specific for a service, script or business object operation:
# specified a value for individual service
In the example above a value specific for service CILTPD was specified.
To implement the transaction timeouts for your site then the following files need to be updated:
Note: Changing this file manually may lose changes across upgrades. If the changes need to be preserved across upgrades then it is recommended to implement a custom template for this file. Refer to the Operations & Configuration Guide or Server Administration Guide supplied with your product for details of this process.
The timeout specification is flexible and powerful but can be overused if over configured. The following guidelines should be taken into account when using this facility:
Specify global defaults (*.default parameters) according to your site expectations and any service level agreements.
Consider the same common value for global defaults unless the customizations at your site dictate different values for each object type default.
Only set overrides on specific objects/services/scripts on the subset of these objects that are critical to your site and require explicit different timeout values from the relevant defaults. In other words, avoid setting overrides on all services individually.
In portals, each zone may have different timeout values. Take this into account when designing timeout values.
Review timeout values with the business on a regular basis to see if the value currently set is appropriate for the site.