[jira] [Commented] (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=14984966#comment-14984966 ] Mark Thomas commented on DBCP-427: -- Happy to see the default change in 2.2. > 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.2 > > 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] [Commented] (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=14984581#comment-14984581 ] Gary Gregory commented on DBCP-427: --- Seems OK to change with a caveat: It might be the case that some drivers use incorrect SQL codes, or use no SQL codes. I would want to have per driver SQL code list. We could also have a general SQL code list. > 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.2 > > 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] [Commented] (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=14651254#comment-14651254 ] Phil Steitz commented on DBCP-427: -- I agree that the default should be changed. We can't do this in a patch release, though; so pushing to 2.2. > 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.2 > > 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] [Commented] (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 commented on DBCP-427:
--
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)
