JBossDeveloper

Just to clarify what I have written before: I didn't mean to cause the transactional threads to be interrupted, I just meant that if you simply call shutdown on the two ReapertWorker threads as far as I understand by looking at the code and by making a couple of tests, they obviously actually won't shutdown if they are in waiting state (that is: ReaperThread is at reaperObject.wait(sleepPeriod) while ReaperWorkerThread is at _theReaper.waitForCancellations() or _theReaper.doCancellations()).

Thank you! This actually helped! Do you suggest any preferred order in shutting down ReaperThread and ReaperWorkerThread?

"adinn" wrote:

ReaperThread appears to have implemented a public shutdown() method since 4.2.1. This does not appear to have been called by the TransactionReaper in 4.2.1 or later releases. Since the thread is private this means there was no shutdown API from 4.2.1 onwards.

I added a similar shutdown method to class ReaperWorkerThread when I created it in 4.3.0. Given the lack of a shutdown API for TransactionReaper I did not add any call to this latter shutdown method.

If Transaction Reaper simply calls the two private shutdown methods for the Reaper and ReaperWorker threads then they will exit. However, this may still leave transactions running without anything to time them out which may or may not have the desired effect. I'm not sure what would be better but here are some thoughts.

Preventing the transaction from committing might be appropriate (if we do this as per the ReaperWorker thread that means calling e.cancel() and, if that fails then e.prevent_commit()).

Waiting for all currently active transactions to remove themselves from the reaper list before returning from the shutdown API might also be desirable.

Interrupting transactional threads is a non-starter as far as I am concerned. For a start what threads? There may not be anything running any code associated with the TX at the point of shutdown. Even if there is a candidate thread, interrupting it at an arbitrary point is a really, really dumb idea (no, don't ask me how dumb -- you will regret it).

So, if we a do add a public shutdown call on TransactionReaperaddingthen it might be useful to add flags to configure whether to call cancel/preventCommit and/or whether to wait for TX exits.