MySQL KILL QUERY and HikariCP validation: can the pool detect a transaction left by a cancelled statement?

When a long‑running DML statement is terminated with KILL QUERY, MySQL aborts the statement but leaves the surrounding transaction open. The storage engine may still be rolling back row changes, which determines when locks are actually released. Meanwhile, a Java connection pool such as HikariCP typically validates a borrowed connection with a lightweight query like SELECT 1. That validation succeeds even if the transaction is still active, so the next borrower can inherit an uncommitted transaction.

The interaction between MySQL’s cancellation primitive and the pool’s validation logic is not fully specified. It is unclear whether KILL QUERY guarantees immediate lock release or whether the pool can reliably detect the intermediate state without additional transaction‑state checks.

• Does KILL QUERY on a DML statement release row locks instantly, or does the engine finish its internal rollback first?
• Can HikariCP’s default validation query detect an open transaction left by a cancelled statement?