Is it safe to stop() a thread that is iterating through a BDB database?

Hi,

I'm using JE 2.0.83. My application opens BDB environments in
Read-Only mode. It spawns threads to handle requests. Each thread
opens cursors to several BDB databases and iterates through the
databases. -- occasionally, a thread may take too long to finish the
query, and I'd like to safely kill the thread (so the CPU doesn't waste
any more time performing that query). Is it safe to call
Thread.stop() on a thread that may have open cursors and is currently
iterating through a BDB database?

I know that Thread.stop() is deprecated because it forces the immediate
release of all monitors that the thread has locked, and may result in
an inconsistent state of shared objects... Is this an issue when
iterating through BDB databases in a read-only environment?

Much Thanks,
~Heng

Is it safe to call
Thread.stop() on a thread that may have open cursors and is currently
iterating through a BDB database?

The short answer is no it is not safe. You need to call the
Cursor.close() method. Otherwise, you will have a resource link and
possible deadlocks.

http://www.sleepycat.com/jedocs/java...or.html#close()

Ron

Thanks for the timely response.
Just want to confirm that even with a Read-Only environment, and a
cursor opened with a NULL transaction, we still have the resource leak
and deadlock issue if we call Thread.stop() on the thread that is
iterating through the db...

If so, then we'll probably wind up implementing a polling mechanism
where the running thread checks the value of a flag and gracefully
stops the iteration and closes the cursor if that flag is set... if
there are other suggestions or insights, please let me know.
Thanks,
~Heng

First, note that Thread.stop was deprecated in Java 1.4, and can cause
lockup problems in the JVM. The javadoc for java.lang.Thread explains
the situation.

Secondly, calling Thread.stop on an executing JE thread will not only
open the door to possible resource leakage, even in a non-transactional
environment, as Ron indicates, it may actually provoke a
com.sleepycat.je.RunRecoveryException if the stop() call catches a
thread in an I/O operation. See the following FAQ for an explanation of
why this is so, and a suggested alternative using Object.notify() and
Object.wait(). Notify and wait() are probably more efficient
alternatives to polling.

http://dev.sleepycat.com/resources/f...i on%3Dsearch
Linda Lee