The HikariDataSource.getConnection() method does not implement a fair borrow mechanism

[xipki]

I am using HikariCP to manage the database connections in my open source project. It works great, thanks.

However, if the application has more threads than the maximal database pool size, the getConnection()may require unbelievable much time to return a connection. In my test case (HikairiCP v4.0.3, with 4 threads and 2 maximal pool size), the average time is 1,3 ms, but 71 of 15485 calls needed more than 100 ms, and one even required 456 ms. Below is the detailed output.

Test borrow-then-close with 4 threads, and 2 max. pool size, for 10 seconds
...
processed 15485 borrow-then-close actions, with 0 failures in 10 seconds
Average borrow action time: 1.285 ms (milli seconds)
71 borrow actions taken more than 100 ms (milli seconds)
max time: 219 ms
...
max time: 329 ms
...
max time: 133 ms
...
max time: 456 ms
...

Attached is the code to reproduce the result above.
SlowBorrowReproducerMain.java.txt

[quaff]

The constructor for this class accepts an optional fairness parameter. When set true, under contention, locks favor granting access to the longest-waiting thread. Otherwise this lock does not guarantee any particular access order. Programs using fair locks accessed by many threads may display lower overall throughput (i.e., are slower; often much slower) than those using the default setting, but have smaller variances in times to obtain locks and guarantee lack of starvation.

Should we need fair lock?