Application Server Retry Policy for Business Method Exceptions

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Application servers face inefficiencies in retrying business methods after exceptions, leading to complex and error-prone client application retry logic, unnecessary re-execution of entire method invocation chains, and resource-intensive post-processing.

Innovation Solution

Implementing a computer program product that allows for retrying business methods at an application server based on predefined retry policies, determining whether retry conditions are met after an exception is thrown, and re-executing the business method accordingly, thereby avoiding client notification and minimizing re-execution of completed portions of the invocation chain.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If client application retry logic is implemented to handle business method failures, then reliability is improved, but device complexity increases and error-prone conditions arise

Engineering Contradiction:

Improvebusiness method execution reliabilityVSAvoidclient application retry logic complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The invention introduces an intermediary retry mechanism at the application server level that mediates between the business method execution and the client application. The container monitors business method execution and automatically retries failed methods based on predefined policies, eliminating the need for complex client-side retry logic while improving reliability.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The system implements self-service retry capability where the application server's container automatically detects failures and retries business methods without external intervention. The container uses predefined retry policies to determine when and how to retry, making the system self-correcting and reducing client application complexity.

Inventive Principle:

Principle #25Self-service

2Reliability

If the entire business method invocation chain is re-executed after a failure, then reliability is improved, but loss of time increases due to re-execution of completed portions

Engineering Contradiction:

Improvebusiness method invocation chain reliabilityVSAvoidre-execution time of completed portions

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The invention segments the business method invocation chain into individual executable units. When a failure occurs, only the specific failed business method is identified and retried, rather than re-executing the entire invocation chain. This segmentation allows completed portions to be skipped, reducing time loss while maintaining reliability.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The system performs preliminary tracking of execution state within the business method invocation chain. Before retrying, the container identifies which portions have already been completed and preserves their results, so that only the failed method needs to be re-executed, minimizing time loss.

Inventive Principle:

Principle #10Preliminary action

3Reliability

If post-processing retry logic is implemented to handle failures, then reliability is improved, but use of energy increases due to additional resources required

Engineering Contradiction:

Improvefailure handling reliabilityVSAvoidresource usage for post-processing retry logic

Core Design Contradiction:

ReliabilityVSUse of energy by moving object

Solution Approach 1:

The container acts as an intermediary that handles retry logic centrally, eliminating the need for resource-intensive post-processing retry logic in client applications. By consolidating retry functionality at the server level, the system reduces overall resource consumption while maintaining reliability.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS8381030B2Business methods retry optimization

Publication Date: 2013.02.19 SAP SE

AI summary

The present disclosure involves systems, software, and computer implemented methods for retrying business methods at an application server after thrown exceptions. One process includes operations for invoking a business method of an enterprise bean hosted in an enterprise bean container. The operations further include determining whether retry conditions are satisfied after an exception is thrown during execution of the business method. The business method is invoked again based on a predefined retry policy when the retry conditions are satisfied.