[JBoss JIRA] Updated: (JBJCA-30) Allow flushing of connection pool on fatal connection events
by Jesper Pedersen (JIRA)
[ https://jira.jboss.org/jira/browse/JBJCA-30?page=com.atlassian.jira.plugi... ]
Jesper Pedersen updated JBJCA-30:
---------------------------------
Priority: Critical (was: Major)
> 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
> Priority: Critical
> Fix For: 1.0.CR1
>
>
> 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
15 years, 10 months
[JBoss JIRA] Updated: (JBJCA-30) Allow flushing of connection pool on fatal connection events
by Jesper Pedersen (JIRA)
[ https://jira.jboss.org/jira/browse/JBJCA-30?page=com.atlassian.jira.plugi... ]
Jesper Pedersen updated JBJCA-30:
---------------------------------
Fix Version/s: 1.0.CR1
> 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
> Fix For: 1.0.CR1
>
>
> 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
15 years, 10 months