Question

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 ?

Était-ce utile?

La solution

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.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top