I'm not sure if the Thread.interrupt() could be working as you expect. From the Java doc [1]
Unless the current thread is interrupting itself, which is always permitted, the checkAccess method of this thread is invoked, which may cause a SecurityException to be thrown. - If this thread is blocked in an invocation of the wait(), wait(long), or wait(long, int) methods of the Object class, or of the join(), join(long), join(long, int), sleep(long), or sleep(long, int), methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException. - If this thread is blocked in an I/O operation upon an interruptible channel then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a ClosedByInterruptException. - If this thread is blocked in a Selector then the thread's interrupt status will be set and it will return immediately from the selection operation, possibly with a non-zero value, just as if the selector's wakeup method were invoked. - If none of the previous conditions hold then this thread's interrupt status will be set. - Interrupting a thread that is not alive need not have any effect. So I think we have to catch the SecurityException when the thread is can not been interrupted. Also ClosedByInterruptException could be thrown if the thread is doing some I/O operations especially by the socket. Anyway, we could understand the interrupt() could be no effect in some cases, e.g. if the thread is busy with the CPU times, just while(true); I think we had similar timeout handling before but removed it at [2] and the SCB-239 [3]. I can recall that we store the timeout setting in the alpha side rather than the omega side just because the alpha can persistent into the back end database and could resume the compensate operations when recovery from the crash scenario or the omega side is failed. Thanks, Zheng Feng [1] https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt() [2] https://github.com/apache/servicecomb-pack/commit/46096fe2f0f0d3d03fb256ed2fd5f221c0b9e851 [3] https://issues.apache.org/jira/browse/SCB-239 Zhang Lei <zhang_...@boco.com.cn> 于2019年4月24日周三 下午7:09写道： > At present, Omega's timeout only stores to the database, find timeout Tx > transactions and compensation through database scans. This may cause the > commit of the Tx transaction after the compensation. > I think it can be improved TransactionAspect class, Terminates the > execution of the method when the timeout and throws a custom exception > > So we can control the rollback of the transaction within the method when > timeout. I wrote an example to show my thoughts > https://github.com/coolbeevip/playground/tree/master/timeoutaspect-demo < > https://github.com/coolbeevip/playground/tree/master/timeoutaspect-demo> > > You can use ApplicationTest to quickly verify > > Any suggestion? > > > Lei Zhang
