Question

I have a java client which is managing its server calls in new threads to prevent the GUI from freezing.

Even if this is prevented in many places, it is possible that the method will be called again on the same model, for example with different parameters. In such case, I obviously want the newest call, with the most up to date parameters, to be the one “succeeding” and displaying its results.

I have a system which is keeping track of the previously launched Thread, and interrupts it before launching the new one (Thread.interrupt()). The other methods are then checking if they are running in a non-interrupted thread (using if (Thread.currentThread().isInterrupted()) before firing the new results to the GUI elements.

This structure was working with a previous connector to the server, as I was the only one checking the interrupt flag on the process. My problem is that I’m now using EJB method calls in the client, and they react badly to the interrupted thread. Interrupting the Thread during an EJB call will trigger a RuntimeException which is including an InterruptedException. And it doesn’t seem like a normal thing to happen.

Obviously I could catch RuntimeExceptions in every server call and check their cause for the interrupt, but it doesn’t seem very “clean”.

My question is: what can I do in such context? What is the proper way to interrupt a Thread running an EJB method call?

Answer 1

Given the existing architecture, I finally went with catching the RuntimeException from each server call, in such form:

try {
    return getEJBService().getServiceResult(param, param, param);
} catch (RuntimeException e) {
    Throwable cause = e.getCause();
    if (cause instanceof InterruptedException)
        throw (InterruptedException)cause;
    else
        throw e;
}

It’s not really pretty, but at least it allows me to act according to the interruption with my current model.

In the ideal world, one should rather go with one of the solutions given by Rich.