我正在将应用程序的数据库连接池从Apache的DBCP2转换为Hikari。到目前为止，一切都看起来不错，但我遇到了光（Hikari）的connectionTimeout属性的问题。这是一个具有大量流量的Web应用程序，我们的首选行为是在池已满的情况下迅速引发错误，以便某种流量的峰值不会占用我们所有等待处理的请求的线程用于连接。我们宁愿让这些请求出错，因为如果需要的话，我们的绝大多数流量都会在以后重试。
对于DBCP2，我们目前将maxWaitMillis属性设置为1秒。 Hikari的connectionTimeout似乎与此等效，因此我也尝试将其设置为1秒。
但是，当我这样做时，我开始出现“登录超时” SQLException。如果我将connectionTimeout改回默认的30秒，问题就消失了。
重新阅读文档，这些属性之间似乎存在细微的差异。
光的connectionTimeout：
此属性控制a的最大毫秒数 客户端（就是您）将等待池中的连接。如果这 没有连接可用就超过了时间， SQLException将被抛出。最低的可接受连接超时为 250毫秒默认值：30000（30秒）
DBCP2的maxWaitMillis：
池将等待的最大毫秒数（如果有） 没有可用的连接），以便在此之前返回连接 引发异常，或-1无限期等待。
似乎在DBCP2中，maxWaitMillis计时器仅在池已满时尝试借用连接时才启动。当您借用连接时，Hikari的connectionTimeout适用于任何情况，这意味着它也适用于池未满且必须打开新连接的情况。在这种情况下，打开新连接所花费的时间超过1秒，这就是引发SQLException的原因。
我在这里更喜欢DBCP2的方法。如果我要打开新的连接，请花很长时间。池中可用的连接数量有限，因此最多可以等待maximumPoolSize个线程。但是，如果池用尽了，我不希望线程等待，因为可能有无数线程在等待从池中借用连接。这些情况看起来非常不同，应该允许不同的超时时间。
有什么方法可以实现我在Hikari中寻找的行为？