Customize transaction timeout settings and data source connection
properties for IBM® Business Automation
Workflow
Runtime, Workstream Services, and
Business Automation Workflow Authoring
components.
Before you begin
Transaction timeout settings control transaction behavior in Business Automation Workflow:
- default-transaction-timeout
- Transaction timeout in seconds for most Business Automation Workflow operations. Default: 480 seconds (8 minutes).
- default-long-transaction-timeout
- Transaction timeout in seconds for Business Automation Workflow operations that require extended processing time, such as repository operations, instance migration, deployment, and snapshot deletion. Default: 14400 seconds (4 hours).
- totalTranLifetimeTimeout
- Default transaction timeout for Liberty. This setting affects transactions not covered by the other two settings. Default: 120 seconds (2 minutes).
- propagatedOrBMTTranLifetimeTimeout
- Upper limit of the transaction timeout for transactions that run on the server. By default, this setting has no timeout. If you modify this setting, set it to a value larger than default-long-transaction-timeout.
- propagateXAResourceTransactionTimeout
-
Controls whether transaction timeouts propagate to the resource manager (database). When you use
Microsoft SQL
Server Server, set this
property to true in the Liberty configuration to ensure that the database enforces
the same timeout values as the application server. This prevents connection leaks and orphaned
transactions. Default: false
The default values are sufficient for most environments. Modify these values only if your workload requires different timeout thresholds. Improve application performance rather than increasing transaction timeouts.
Procedure
Use 100Custom.xml to customize transaction timeout settings. Use Liberty configuration to customize data source connection properties.
-
If you want to modify default-transaction-timeout or default-long-transaction-timeout, create a 100Custom.xml file with your custom transaction timeout values.
Example 100Custom.xml file with default values:
<properties>
<server merge="mergeChildren">
<!-- Standard transaction timeout in seconds (default: 480) -->
<default-transaction-timeout merge="replace">480</default-transaction-timeout>
<!-- Long transaction timeout in seconds (default: 14400) -->
<default-long-transaction-timeout merge="replace">14400</default-long-transaction-timeout>
</server>
</properties>
-
If you want to modify totalTranLifetimeTimeout or data source tuning settings for the Business Automation Workflow database, retrieve the current data source configuration from the configmap for your component type.
-
Run the appropriate command for your component type to retrieve the data source configuration.
For Business Automation Workflow Authoring:
kubectl get configmap cr-name-bastudio-overrides-configmap -n namespace -o yaml
For Business Automation Workflow Runtime:
kubectl get configmap cr-name-baw-server-configmap-liberty -n namespace -o yaml
Locate the datasource.xml section in the output.
-
Copy the existing data source configuration and modify it with your custom settings.
Important: Customize Liberty transaction manager and data source settings for performance tuning only if the customization does not interfere with XA transactions.
The following example shows transaction manager and data source connection pool settings:
<server>
<!-- Transaction manager settings -->
<transaction
totalTranLifetimeTimeout="120s"/>
<!-- Data source connection pool settings -->
<dataSource id="BPMDB" statementCacheSize="100">
<connectionManager
maxPoolSize="100"
minPoolSize="10"
connectionTimeout="30s"
maxIdleTime="30m"
agedTimeout="30m"
reapTime="180s"/>
</dataSource>
</server>
For more information about transaction manager settings, see Liberty transaction configuration reference
.
-
Apply your 100Custom.xml configuration and Liberty data source configuration by following the instructions for your environment type.
Results
The Business Automation Workflow components use the customized settings.
Review the pod logs to confirm that the settings loaded correctly.