raphw

Great, then this will work just fine for the use cases that I had in mind! Thanks for taking care of this.

I see, but I am wondering: is there an exception thrown? How would I know as a user that the statement was rolled back? The interrupt could have been set just after the statement completed; is there an exception thrown?

I'd recommend to not rollback the transaction. I would not expect this to have happened from an interrupt.

Hi Fred, thanks for your detailed answer, I am glad that you are adressing the problem. I am using HSQLDB in a unit test scenario. We do also test everything in Docker against Oracle and Postgres databases that we use in production but for quick feedback HSQLDB works amazingly well as a substitute for some tests, even for the more complicated queries. Congrationaltions to you for maintaing such a magnificent tool! As for the JDBC behavior, the swallowed interrupts are a major difference between using...

Hi Fred, thanks for your detailed answer, I am glad that you are adressing the problem. I am using HSQLDB in a unit test scenario. We do also test everything in Docker against Oracle and Postgres databases that we use in production but for quick feedback HSQLDB works amazingly well as a substitute for some tests, even for the more complicated queries. Congrationaltions to you for maintaing such a magnificent tool! As for the JDBC behavior, the swallowed interrupts are a major difference between using...

This is not feasible in many cases. Take this scenario for example: A user controls multiple background task via a GUI and wants to start and stop individual tasks. To stop a task, the specifc thread is sent an interrupt to signal its termination. If that thread is by chance executing a JDBC statement in the particular moment, this wish for termination will be suppressed. The only workaround is currently to spam the thread with interrupts to hopefully hit a moment when no JDBC statement is executed....

Interruption flag is cleared during statement execution

The tools do verify the classes that they try to modifiy but as I explained, they can only discover that the modification was made impossible after ProGuard removed the metadata. By rendering the local variable array as empty, this would imply that the above void bar(String s) method would neither have a 'this' ot 's' variable declared as it is no longer legal to access those after the empty frame. javac or any other JVM-language compiler only removes temporary variables from frames after leaving...