[cbredesen]

The original point of this feature involves the ability to purge based on the assumption that all connection are invalid (configurable of course). So at least one of the options can't rely on a VCC or sql to be present. I believe this is what you mean by "idle connections" i.e. pool.flush() which makes perfect sense. I proporsed a slightly different angle on this in the JIRA, which is three behaviors upon fatal ex:

- destroy single
- initiate validation
- flush pool

[adrian.brock]

"cbredesen" wrote:
The original point of this feature involves the ability to purge based on the assumption that all connection are invalid (configurable of course). So at least one of the options can't rely on a VCC or sql to be present. I believe this is what you mean by "idle connections" i.e. pool.flush() which makes perfect sense. I proporsed a slightly different angle on this in the JIRA, which is three behaviors upon fatal ex:

- destroy single
- initiate validation
- flush pool

Ok, but "initiate validation" could be an orthogonal option on background the validation
config.

<background-validation validate-on-error="true"/>

Without background validation enabled, the thread that gets the error
is going to have to do a lot of work for large pools.