See: Description
| Interface | Description |
|---|---|
| RetryEventListener |
Interface for receiving a retry event.
|
| RetryState |
Internal retry state.
|
| RetryStrategy |
Interface for a retry strategy.
|
| SqlCallable<V> |
A SAM type permitting the use of lambda expressions whose default action is
to perform a SQL transaction using the given connection.
|
| SqlTransactionContext |
The SQL transaction context for executed actions.
|
| TransientExceptionDetector |
Defines an interface to detect for transient error conditions.
|
| Class | Description |
|---|---|
| BasicSqlTransactionContext |
A basic transaction context wrapping a java.sql.DataSource.
|
| ExponentialBackoff |
Implements truncated binary exponential backoff to calculate retry delay per
IEEE 802.3-2008 Section 1.
|
| FixedInterval |
Represents a fixed interval RetryStrategy whose time interval is fixed.
|
| Incremental |
Implementation for an incremental retry strategy with fixed initial and
incremental wait times.
|
| RetryEvent |
Represents current retry state.
|
| RetryPolicy<V> |
A generic retry policy.
|
| RetryState.RetryStateCommon |
Basic utilities for retry strategies.
|
| SqlRetryPolicy<V> |
A retry policy for SQL operations.
|
| SqlTransientExceptionDetector |
Checks if the exception is a transient SQL exception.
|
This package contains the core retry framework classes; this page provides descriptions for the core classes, the key concepts, etc.
There are four primary components to the retry framework:
Detectors distinguish transient exceptions from non-transient exceptions. Transient exceptions are those that are retryable; non-transient exceptions are those that, no matter how many times you retry, will invariantly yield the same exceptions.
Examples of transient exceptions are socket closed, lock conflicts, etc. Examples of non-transient exceptions are syntax errors.
Retry strategies are algorithms that govern the behavior related to the the application of retry, the amount of time between retries, whether or how retry intervals change duration for each subsequent retry, etc.
There are several retry strategies available:
The framework can be easily extended to support retry for arbitrary use cases, such as for database, and communications. Out of the box the framework provides two retry policies, a generic retry Policy applicable to communications and similar patterns, then a SqlRetryPolicy applicable to JDBC usage scenarios.
Copyright © 2015. All rights reserved.