Calling {@code Thread.interrupt} is not recommended for an active JEthread if the goal is to stop the thread or do thread coordination. If you interrupt a thread that is executing a JE operation, the state of the environment will be undefined. That's because JE might have been in the middle of I/O activity when the operation was aborted midstream, and it becomes very difficult to detect and handle all possible outcomes.
When JE detects the interrupt, it will mark the environment invalid and will throw a {@code ThreadInterruptedException}. This tells you that you must close the environment and re-open it before using it again. This is necessary, because if JE didn't throw {@code ThreadInterruptedException}, it is very likely that you would get some other exception that is less meaningful, or simply see corrupted data.
Instead, applications should use other mechanisms like {@code Object.notify} and {@code wait} to coordinate threads. For example, use a{@code keepRunning} variable of some kind in each thread. Check thisvariable in your threads, and return from the thread when it is false. Set it to false when you want to stop the thread. If this thread is waiting to be woken up to do another unit of work, use {@code Object.notify} to wake itup. This is the recommended technique.
However, if the use of {@code Thread.interrupt} is unavoidable, be sureto use it only when shutting down the environment. In this situation, the {@code ThreadInterruptedException} should be expected. Note thatby shutting down the environment abnormally, recovery time will be longer when the environment is subsequently opened, because a final checkpoint was not performed.
Existing {@link Environment} handles are invalidated as a result of thisexception.
@since 4.0 | |