Transaction Availability Indicator for Processing Overload
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Transaction processing environments face performance degradation due to the overhead of creating and abending transactions when operating close to their limits, leading to resource contention and queuing issues during peak workloads.
Innovation Solution
A method for determining the availability of transactions in a processing environment by calculating a smoothed count of in-flight requests, allowing for the rejection of new transactions when the system is overloaded, thereby avoiding unnecessary resource allocation and queuing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If new transactions are created and queued when the system is near its operational limits, then the system attempts to handle all incoming work, but this causes performance degradation due to the overhead of creating, dispatching, and abending transactions
Solution Approach 1:
The system performs preliminary checking of the availability indicator before creating new transactions. By evaluating the smoothed count of in-flight requests in advance, the system prevents the creation of transactions that would likely be abended, avoiding the overhead of initializing, dispatching, and subsequently abending them. This preliminary action filters out problematic transactions before they consume system resources.
Solution Approach 2:
The availability indicator acts as an intermediary mechanism between incoming transaction requests and the transaction creation process. This indicator, based on the smoothed count of in-flight requests, mediates whether new transactions should be created by providing a threshold-based decision criterion that balances workload acceptance with system capacity.
2Adaptability or versatility
If the system accepts all incoming transaction requests, then maximum workload handling is attempted, but this leads to queuing delays and performance degradation when operating near MAXTASK and MAXACTIVE limits
Solution Approach 1:
The system implements feedback through the availability indicator that continuously monitors the smoothed count of in-flight requests. This feedback mechanism dynamically adjusts transaction acceptance by comparing the current workload state against predefined thresholds, allowing the system to adaptively accept or reject transactions based on real-time conditions rather than static limits.
Solution Approach 2:
The system transitions from static transaction limits (MAXTASK, MAXACTIVE) to a dynamic availability indicator based on smoothed in-flight request counts. This dynamic approach allows the system to flexibly adjust its transaction acceptance criteria in response to changing workload conditions, improving adaptability while preventing excessive queuing delays.
3Ease of operation
If the system creates transactions that will later be abended due to threshold violations, then all work is initially accepted, but this wastes system resources on transactions that must be torn down
Solution Approach 1:
The system performs preliminary evaluation of the availability indicator before creating transactions. By checking whether the smoothed count of in-flight requests is below the threshold, the system prevents creation of transactions that would violate MAXTASK or MAXACTIVE limits, avoiding the resource waste associated with subsequent abending operations.
Solution Approach 2:
The system converts the potentially harmful effect of transaction abending (resource waste and performance degradation) into a beneficial filtering mechanism. By using the availability indicator to preemptively reject transactions that would likely be abended, the system transforms what would be a harmful resource waste scenario into a beneficial resource conservation strategy.
Data Source
AI summary
A determination is made whether a requested transaction of a certain type or class is available (i.e., suitable for execution or queueing) within a processing environment. In the case that a transaction of the certain type or class is not available, the request to be rejected is enabled, thus avoiding queuing of the requested transaction. Embodiments may thus provide a mechanism to protect a processing environment by avoiding the overhead of creating and removing specific transactions of the certain type or class.