Berkeley DB Family

hi,
i was wondering what the rationale was on the bdb policy to invalidate an environment when a thread interrupt is encountered? we are using bdb in a generic sub-system where job cancellation is forced through Thread.interrupt. if the underlying operation happens to be doing something bdb related, the environment gets borked and needs to be restarted. this is less than ideal. now, as a somewhat similar comparison, if i'm doing some sort of jdbc operation on a database and the thread is interrupted, the current transaction will be rolled back, and everything will probably be hunky-dory. i can understand why things get tricky when handling interrupts, especially for non-transacted environments. but, couldn't transacted environments still cleanly handle the interrupt by rolling back the current transaction? i know the "workaround" is to put custom state handling in your code and use that instead of Thread.interrupt. But that means that all possibly long running code needs to be aware of this "alternate" cancellation mechanism, whereas Thread.interrupt is already a universal implementation of this concept. Is there any chance this could be handled differently in the future?
thanks,
-james