To further clarify: All that was about the JDBCConnectionPool class. On Aug 5, 12:51 am, Joe <[email protected]> wrote: > 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.
