[
https://issues.apache.org/jira/browse/DBCP-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Konkov reopened DBCP-427:
----------------------------------
Phil, configuration property is fine, but it default value 'false' is unoptimal:
1. As described in this tiket - there is NO WAY to detect broken XA connection
without fail fast behaviour (proofed on MS SQL JDBC and Oracle JDBC). So BY
DEFAULT connection will leak.
2. It is normal to throw away connection that reports explicitly 'I'm broken'.
Selected codes is 100% proofed by manufacturer and many developers. And If (and
only if) something is incorrect - you provide option to disable that validation.
Please, reconsider default value, because XA case is broken and so few
developers will find new option to enable. Moreover in many cases there is no
way to enable it because of lack of support to set custom options on DBCP pool
when used as embeded (pax-jdbc, DataNuclues and may be more).
> 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)
