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

[Jay Howell (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBJCA-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12443373#action_12443373 ] 

Jay Howell commented on JBJCA-30:
---------------------------------

Number #1 might be the hack that goes into a CP if it has to, but the better way to fix this is to add this into the JCA adapter.  Since this impacts both JDBC and JMS pieces of the adapter, it's something that should probably go in as  a pooling parameter.

Upon callback to the pool that a connection is bad, the entire pool could be flushed if configured to do so.  

Jay:)

> Allow flushing of connection pool on fatal connection events
> ------------------------------------------------------------
>
>                 Key: JBJCA-30
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-30
>             Project: JBoss JCA
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Chris Bredesen
>            Assignee: Jesper Pedersen
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira