Depending on the nature of the failure, this exception may indicate that {@link Environment#close} must be called. The application should catch{@code EnvironmentFailureException} and then call {@link Environment#isValid}. If {@code false} is returned, all {@code Environment}handles (instances) must be closed and re-opened in order to run recovery and continue operating. If {@code true} is returned, the {@code Environment} can continue operating without being closed and re-opened.Also note that {@link Environment#isValid} may be called at any time, notjust during exception handling.
The use of the {@link Environment#isValid} method allows JE to determinedynamically whether the failure requires recovery or not, and allows for this determination to change in future releases. Over time, internal improvements to error handling may allow more error conditions to be handled without invalidating the {@code Environment}.
(Although this exception class extends {@link RunRecoveryException}, it does not always indicate that recovery is necessary, as described above. {@code RunRecoveryException} has been deprecated and {@code EnvironmentFailureException} should be used instead.)
If an {@code EnvironmentFailureException} consistently occurs soon afteropening the Environment, this may indicate a persistent problem. It may indicate a system problem or a persistent storage problem. In this case, human intervention is normally required and restoring from a backup may be necessary.
Note that subclasses of {@code EnvironmentFailureException} indicate howto handle the exception in more specific ways.
If {@link Environment#close} is not called after an {@code EnvironmentFailureException} invalidates the {@code Environment}, all subsequent method calls for the {@code Environment} will throw the sameexception. This provides more than one opportunity to catch and handle the specific exception subclass that caused the failure.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|