Our application had been using ping based approach where in before each query is executed.validation query is fired to check whether the connection is live or not. DataSource config for the same is as below:

  <min-pool-size>10</min-pool-size>
    <max-pool-size>250</max-pool-size>
    <blocking-timeout-millis>90000</blocking-timeout-millis>
    <track-statements/>
    <new-connection-sql>SELECT 1</new-connection-sql>
    <check-valid-connection-sql>SELECT 2</check-valid-connection-sql>.

Now in this approach we could see that there were tons of times when 'select 1' sql was getting executed and was unnecassarily adding upto the total cost for the operation.

When I searched for the possible alternatives was to do the connection checking in the background.

Datasource config for the same is as below:

<min-pool-size>10</min-pool-size>
<max-pool-size>250</max-pool-size>
<blocking-timeout-millis>90000</blocking-timeout-millis>
<track-statements/>
<new-connection-sql>SELECT 1</new-connection-sql>
<check-valid-connection-sql>SELECT 2</check-valid-connection-sql>
<validate-on-match>false</validate-on-match>
<background-validation>true</background-validation>
<background-validation-millis>600000</background-validation-millis>

My question is is this recommended?Is there any negatives if we used above approach ?

有帮助吗?

解决方案

It's not the default behaviour, but it's a perfectly good option when you have very frequent queries, like in your case. You are right, this will significantly improve the latency of your queries.

The only downside is if something wrong happens to the connection between the validation period background-validation-millis. In this case, your query will fail, so, review your error handling code. I think it's a pretty cheap price to pay for the performance increase you might get.

Hope this helps.

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top