This code does not belong in the managed connection pool.
The pool is protected by a lock (the permits semaphore).

If the thread comes in a interrupted it can be assumed it should not
be attempting to use more resources.

Your bug report shows where the thread's interrupted status is not what
you expected. It has been interrupted because the suspended transaction
(on the same thread) timed out.

IMHO, the exception should be thrown if the transaction is trying to get
access to managed resources after a transaction timeout.
The issue is what todo about other contexts on the thread not associated
with the timed out transaction, i.e. the equivalent of RequiresNew or NotSupported
ejb invocations.