The problem is that the accuracy of System.currentTimeMillis() is dependent on the underlying OS and can be as big as tens of ms.
Because of this, the elapsed time condition can return false and a new round of waiting will start, leading to a double apparent checkout wait time.
There is no theorically correct solution since all clocks do not have a perfect resolution, but using alternative like nanotime can mitigate the problem.
Another solution is to wait the remaining time in the next round of waiting.
In BasicResourcePool,
System.currentTimeMillis()is used to check the tiemout status of a checkout : https://github.com/swaldman/c3p0/blob/c5471304cc7a155d1c5b23a59579b3e996013a28/src/java/com/mchange/v2/resourcepool/BasicResourcePool.java#L1504The problem is that the accuracy of
System.currentTimeMillis()is dependent on the underlying OS and can be as big as tens of ms. Because of this, the elapsed time condition can return false and a new round of waiting will start, leading to a double apparent checkout wait time.There is no theorically correct solution since all clocks do not have a perfect resolution, but using alternative like nanotime can mitigate the problem.
Another solution is to wait the remaining time in the next round of waiting.
What do you think ?
Thanks