https://issues.apache.org/bugzilla/show_bug.cgi?id=52066
Bug #: 52066
Summary: ConnectionPool.borrowConnection swallows interrupt
state.
Product: Tomcat Modules
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: jdbc-pool
AssignedTo: [email protected]
ReportedBy: [email protected]
Classification: Unclassified
In this code snippet starting on line 6.15 of ConnectionPool.java version
7.0.22
try {
//retrieve an existing connection
con = idle.poll(timetowait, TimeUnit.MILLISECONDS);
} catch (InterruptedException ex) {
Thread.interrupted();//clear the flag, and bail out
SQLException sx = new SQLException("Pool wait interrupted.");
sx.initCause(ex);
throw sx;
} finally {
waitcount.decrementAndGet();
}
The line marked '//clear the flag, and bail out' is wrong, because after that
there is no way for calling code to find out that the thread has been
interrupted.
The correct behavior should be
Thread.currentThread( ).interrupt( );
Here is the excerpt from the Biran Goetz's "Java Concurrency in Practice"
chapter 5.4.
<!START QUOTATION>
For library code there are basically two choices:
-- Propagate the InterruptedException. This is often the most sensible policy
if you can get away with it -- just propagate the InterruptedException to your
caller. This could involve not catching InterruptedException, or catching it
and throwing it again after performing some brief activity-specific cleanup.
-- Restore the interrupt. Sometimes you cannot throw InterruptedException, for
instance when your code is part of a Runnable. In these situations, you must
catch InterruptedException and restore the interrupted status by calling
interrupt on the current thread, so that code higher up the call stack can see
that an interrupt was issued.
<!END QUOTATION>
In the case of borrowConnection, #1 is not really a choice, as it is running in
the confines of JDBC interface. But it can definitely restore the interrupt
status of the thread.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
