-
1. Re: Bug Report 1074790: Interpretation of thread interruptio
So let me clarify my workaround. My code thats starts the nested transaction looked like this:
TransactionManager mgr = getManager();
mgr.suspend();
mgr.begin();
... (do stuff in new transaction)
... (commit or rollback)
mgr.resume();
where the "stuff" in the new transaction is requesting a new JDBC connection, which is triggering the "Interrupted while requesting permit" exception because the suspended transaction caused the thread to get interrupted (e.g. due to a tx timeout.) My code with the workaround is now:
TransactionManager mgr = getManager();
Thread.interrupted();
mgr.suspend();
mgr.begin();
... (do stuff in new transaction)
... (commit or rollback)
mgr.resume();
so that the interrupted status is cleared from the thread. It seems like TransactionManager.begin() should be responsible for resetting the interrupted status, and (as a separate issue) that InternalManagedConnectionPool should be clearing the interrupted status before calling permits.attempt(), which is what is throwing the InterruptedException. See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=52329 for more details. -
2. Re: Bug Report 1074790: Interpretation of thread interruptio
The purpose of the thread interruption is to avoid the thread getting
stuck in long running processes which it never recovers from.
e.g. waiting in db i/o, or attempting to wait on a lock
The interruption is a one-time operation (at transaction timeout)
so if somebody else eats it there will be nothing to stop the problems
mentioned above.
Whatever does check for interruption should also restore the state
on exit, i.e. your example code should be:
TransactionManager mgr = getManager();
boolean interrupted = Thread.interrupted();
try
{
mgr.suspend();
mgr.begin();
... (do stuff in new transaction)
... (commit or rollback)
mgr.resume();
finally
{
if (interrupted)
Thread.currentThread().interrupt();
} -
3. Re: Bug Report 1074790: Interpretation of thread interruptio
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. -
4. Re: Bug Report 1074790: Interpretation of thread interruptio
Sorry to be resurrecting a very old issue, but we are encountering this same problem with 3.2.7. We have a long running process. This used to work fine, but I guess the execution time has grown as our database has grown. I see the job starting at 21:28:31, then getting this "Interrupted while requesting permit!" at 21:38:32. So I suppose some timeout is happening at 10 minutes = 600 seconds.
I'm not really following the discussion here or in the bug report. Is this happening because the job overlaps the 30-minute database connection timeout, and hence the connection is getting yanked out from underneath it? I would think not, because that should produce some error reflecting loss of connection.