Automatic Retry of Container-Managed Transactions
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing systems for managing transactions in EJB containers require explicit coding for retrying failed transactions, which is cumbersome and can lead to performance degradation, especially in concurrent environments where database deadlocks and optimistic concurrency exceptions occur.
Innovation Solution
Implementing automatic retry of container-managed transactions, allowing the EJB container to retry failed transactions up to a specified number of times without the need for explicit coding, either through deployment descriptors or runtime settings, thereby alleviating the burden on developers and improving performance by localizing retries within the same JVM.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If explicit retry coding is implemented in EJB methods, then transaction reliability is improved, but device complexity and ease of operation deteriorate due to increased code burden and tedious source code
Solution Approach 1:
The EJB container automatically performs transaction retries without requiring explicit retry logic in the EJB method code. The container monitors transaction outcomes and autonomously re-invokes the method when rollbacks occur, allowing the system to self-correct transaction failures without developer intervention in the retry mechanism.
Solution Approach 2:
The EJB container acts as an intermediary between the EJB method and the transaction management system. It intercepts transaction outcomes, determines whether retries are necessary based on rollback exceptions, and coordinates re-invocations, thereby shielding the EJB method from complex retry logic while maintaining transaction reliability.
2Reliability
If explicit retry coding is implemented, then transaction reliability is improved, but productivity deteriorates due to performance degradation in remote network invocations
Solution Approach 1:
The container autonomously manages retry logic locally within the JVM, eliminating the need for remote network round-trips that would occur with explicit client-side retry coding. This local automation reduces network overhead and improves transaction processing speed while maintaining reliability.
Solution Approach 2:
The retry logic is segmented from the EJB method implementation and placed in the container's transaction management layer. This separation allows the method itself to remain simple while the container handles the complex retry coordination, reducing overhead in remote invocations by managing retries at the container level rather than through repeated method invocations.
3Ease of operation
If automatic retry is implemented at the container level, then ease of operation is improved, but device complexity increases due to container configuration requirements
Solution Approach 1:
The EJB container provides a universal retry mechanism that works across all EJB methods without requiring method-specific retry logic. By making retry functionality a general container capability rather than a method-specific feature, the system simplifies developer operations while the configuration complexity is centralized in the container's deployment descriptor rather than scattered throughout the codebase.
4Reliability
If multiple retry attempts are allowed, then transaction reliability is improved, but loss of time increases due to additional retry cycles
Solution Approach 1:
The system implements a limited number of retry attempts (typically 1-3 retries) rather than unlimited retries. This partial action approach provides sufficient reliability improvement to handle transient failures like deadlocks and optimistic concurrency exceptions, while avoiding excessive time loss that would result from numerous retry cycles. The retry count is tuned to balance reliability gains against time consumption.
Data Source
AI summary
The feature of automatic retry of container-managed transactions configures the container to allow automatic retries of container-managed transactions that have been rolled back due to exceptions thrown at runtime. More specifically, on a per method basis, the container can be instructed to retry a failed transaction as using a new one up to a specified number of times if that method was the originator of the transaction that has been rolled back. The enabling of automatic transaction retries is accomplished either at deployment time by setting properties in the deployment descriptor of an instance of a class, such as EJB, or at runtime by setting properties on the EJB via a console on the application server. The automatic retry of container-managed transactions is a convenient feature that may alleviate the client of the task of explicitly coding transaction retries. In addition to programming convenience, retrying transactions using this feature may also offer performance benefits. This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.