Couple of thoughts: 1) The JDBCConnectionPool setLoginTimeout method says the default timeout is 5 minutes. However, the default is actually set to '30' in the code. That appears that is supposed to be '30' seconds.
2) The timeout mechanism for obtaining a connection appears dangerous to me when connections are under high contention. With most operations in the pool calling notifyAll and with the 'wati(1000)' being used as the delay mechanism for getting a connection it seems to me that a waiter for a connection could get starved because there is no fairness in waiting that way and further could not actually wait the full '30 seconds' since the waiting mechanism really has little to do with time but rather being notified is more likely. - It seems it would be nice to have a more fair waiting mechanism which became much easier in Java 6 concurrent lib. - It would make sense to not simply loop on '30' whatever (could be seconds, could be interrupts, could be spurious, could be notifyAll) and instead track the actual wait time in milliseconds. This way it will truly wait that long. This by itself doesn't solve the fairness problem but at least you'd know you truly did wait the full login timeout period. Does any of this make sense or am I reading that code incorrectly? -- 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.
