[jboss-jira] [JBoss JIRA] Resolved: (JBJCA-30) Allow flushing of connection pool on fatal connection events

[Jesper Pedersen (JIRA)]

     [ https://issues.jboss.org/browse/JBJCA-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-30.
----------------------------------

    Resolution: Done


A <flush-strategy> as added to the pool configuration.

Valid values are:

 * FailingConnectionOnly (default)
 * IdleConnections
 * EntirePool


> Allow flushing of connection pool on fatal connection events
> ------------------------------------------------------------
>
>                 Key: JBJCA-30
>                 URL: https://issues.jboss.org/browse/JBJCA-30
>             Project: IronJacamar
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Chris Bredesen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.0.Beta6
>
>
> As an alternative to validating connections (either on borrow or in the background), we could implement a feature similar to WebSphere's purge policy.  The idea is that we can assume in certain cases that a single fatal exception means every connection in the pool will subsequently throw fatal exceptions.  Such is the case in situations where the connected database has been restarted.  Rather than implementing a purge policy per se, we would implement an "on fatal behavior".  The behavior could define one of three actions to be taken when a fatal exception is encountered:
> 1. Destroy single connection (equivalent to WAS policy of "single connection")
> 2. Initiate validation run
> 3. Flush entire pool (equivalent to WAS policy of "whole pool")
> Note that all of the above (indeed this entire feature) requires the use of an ExceptionSorter.
> In terms of implementation, I see two possibilities:
> 1. Implement this feature as an MBean, which means we'd need some way of registering connection event listeners outside JCA.
> 2. Implement this feature as part of the JCA adapter which I think makes more sense, but is more impactful.
> Regarding #1, if it's possible to simply add a way to register connection event listeners from outside the adapter, that could become its own feature request and this feature simply turns into an MBean that can be implemented separately.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira