[jira] [Comment Edited] (DBCP-427) Examines 'SQLException's thrown by underlying connections or statements for fatal (disconnection) errors
[ https://issues.apache.org/jira/browse/DBCP-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14281978#comment-14281978 ] Phil Steitz edited comment on DBCP-427 at 1/18/15 9:56 PM: --- Why not just adapt the BDS invalidateConnection code to immediately invalidate / remove a connection that throws a fatal connection exception. So instead of {code} protected void handleException(SQLException e) throws SQLException { fatalSqlExceptionThrown |= Utils.isDisconnectionSqlException(e); super.handleException(e); } {code} we just do {code} protected void handleException(SQLException e) throws SQLException { if (Utils.isDisconnectionSqlException(e)) { invalidate(); } super.handleException(e); } {code} where invalidate() does what BDS#invalidateConnection does - attempt to close and then remove from the pool. was (Author: psteitz): Why not just adapt the BDS invalidateConnection code to immediately invalidate / remove a connection that throws a fatal connection exception. So instead of {code} protected void handleException(SQLException e) throws SQLException { fatalSqlExceptionThrown |= Utils.isDisconnectionSqlException(e); super.handleException(e); } {code} we just do {code} protected void handleException(SQLException e) throws SQLException { if (Utils.isDisconnectionSqlException(e)) { invalidate(); } super.handleException(e); {code} where invalidate() does what BDS#invalidateConnection does - attempt to close and then remove from the pool. > Examines 'SQLException's thrown by underlying connections or statements for > fatal (disconnection) errors > > > Key: DBCP-427 > URL: https://issues.apache.org/jira/browse/DBCP-427 > Project: Commons Dbcp > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Vladimir Konkov >Priority: Minor > Fix For: 2.1 > > Attachments: DBCP-427_initial_impl.diff > > > Affected cases: > 1. Ability to detect severed connection without need for validity check (it > can be time demand). > 2. Not all fatal errors detected with simple validation query or isValid() > call. For example: > Broken XA connections of MS SQL Server and Oracle Database (and may be other) > pass validation for both isValid() and simple validation query such as 'SELEC > 1 FROM DUAL' but throw fatal errors on data and/or transaction manipulation > calls. Such errors gone only after reconnect. In case of use DBCP for polling > application has no chance to cleanup broken connection. > By providing infractructure for check thrown exceptions and mark > PoolableConnection as poisoned we can cleanup pool on validation phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DBCP-427) Examines 'SQLException's thrown by underlying connections or statements for fatal (disconnection) errors
[ https://issues.apache.org/jira/browse/DBCP-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259506#comment-14259506 ] Phil Steitz edited comment on DBCP-427 at 12/29/14 2:54 AM: I like the idea here and the patch looks OK, except that I think this behavior should be configurable. was (Author: psteitz): I like the idea here and the patch looks OK, except that I think this behavior should be configurable. Also, a related feature that has been requested before and could be incorporated here is a method allowing client applications to explicitly mark connections as invalid. > Examines 'SQLException's thrown by underlying connections or statements for > fatal (disconnection) errors > > > Key: DBCP-427 > URL: https://issues.apache.org/jira/browse/DBCP-427 > Project: Commons Dbcp > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Vladimir Konkov >Priority: Minor > Fix For: 2.1 > > Attachments: DBCP-427_initial_impl.diff > > > Affected cases: > 1. Ability to detect severed connection without need for validity check (it > can be time demand). > 2. Not all fatal errors detected with simple validation query or isValid() > call. For example: > Broken XA connections of MS SQL Server and Oracle Database (and may be other) > pass validation for both isValid() and simple validation query such as 'SELEC > 1 FROM DUAL' but throw fatal errors on data and/or transaction manipulation > calls. Such errors gone only after reconnect. In case of use DBCP for polling > application has no chance to cleanup broken connection. > By providing infractructure for check thrown exceptions and mark > PoolableConnection as poisoned we can cleanup pool on validation phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)