Hi,
Attached goes a candidate patch that almost solve the premature exit
of getConnection() method.
Use it as sees fit.
regards,
Dario.
--------------------------------------------------------------------------------------------------
# This patch file was generated by NetBeans IDE
# Following Index: paths are relative to: h2database-read-only/h2/src/
main/org/h2/jdbcx
# This patch can be applied using context Tools: Patch action on
respective folder.
# It uses platform neutral UTF-8 encoding and \n newlines.
# Above lines and this line are ignored by the patching process.
Index: JdbcConnectionPool.java
--- JdbcConnectionPool.java Remotely Modified (Based On HEAD)
+++ JdbcConnectionPool.java Locally Modified (Based On LOCAL)
@@ -194,14 +194,12 @@
* or a timeout occurred
*/
public Connection getConnection() throws SQLException {
- for (int i = 0;; i++) {
+ final long exittime = System.currentTimeMillis()+
(timeout*1000L);
+ while (exittime > System.currentTimeMillis()) {
synchronized (this) {
if (activeConnections < maxConnections) {
return getConnectionNow();
}
- if (i >= timeout) {
- throw new SQLException("Login timeout", "08001",
8001);
- }
try {
wait(1000);
} catch (InterruptedException e) {
@@ -209,6 +207,7 @@
}
}
}
+ throw new SQLException("Login timeout", "08001", 8001);
}
private Connection getConnectionNow() throws SQLException {
--------------------------------------------------------------------------------------------------
On Aug 6, 6:51 am, Thomas Mueller <[email protected]>
wrote:
>
> Yes, it sounds like there is a bug. Unfortunately I don't have time
> now to investigate, but I will try to create a test case and fix the
> problem in about two weeks. If you have time, a test case or even a
> patch would be great of course!
>
> Regards,
> Thomas
>
> On Friday, August 6, 2010, Wildam Martin <[email protected]> wrote:
> > On Fri, Aug 6, 2010 at 05:04, Joe <[email protected]> wrote:
> >> However, I'm still concerned about the mechanism for waiting. It is
> >> 30 'wait cycles' where each wait cycle would complete from one of the
> >> following conditions:
> >> 1) the connection becomes available
> >> 2) the 1000ms wait call completes and the thread resumes
> >> 3) the notifyAll method is called causing the wait to return
> >> immediately (not just after 1000ms).
>
> >> Under high contention for those connections I believe two things can
> >> happen:
> >> - starvation of access to a connection because the waiting mechanism
> >> is unfair
> >> - waiting potentially way less than 30 seconds because the waiting
> >> mechanism isn't really much about time at all (it is about wait/
> >> notifyAll cycles in high contention).
>
> > Thank you for the information.
>
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.