[
https://issues.apache.org/jira/browse/DBCP-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434562#comment-17434562
]
Gary D. Gregory commented on DBCP-582:
--------------------------------------
[~BeateSchatzmann]
Feel free to provide a PR on GitHub so we can all see what this would look
like.
Are all the SQL states you mention part of any of the SQL standards like
SQL-92? Either way, these would have to be documented in code comments so we
know what they each mean. Or maybe they would need to be configured from a
properties file or somesuch.
> Check SQLExceptions in org.apache.commons.dbcp2.cpdsadapter.ConnectionImpl
> --------------------------------------------------------------------------
>
> Key: DBCP-582
> URL: https://issues.apache.org/jira/browse/DBCP-582
> Project: Commons DBCP
> Issue Type: New Feature
> Reporter: Beate Schatzmann
> Priority: Minor
>
> I use _*org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS*_ to connect
> to a postgres database in the connection pool
> _*org.apache.commons.dbcp2.datasources.SharedPoolDataSource*_. I am quite
> happy with it but there is one thing that postgres' ConnectionPoolDataSource
> does better: when the Connection is used and an SQLException occurs then it
> is checked if the Exception is "fatal" - and if this is the case then
> {{javax.sql.ConnectionEventListener.connectionErrorOccurred()}}
> is called, which is handled in
> _*org.apache.commons.dbcp2.datasources.KeyedCPDSConnectionFactory*_ and
> removes the Connection from the pool (i.e. the number of active connections
> is decremented).
> With _*DriverAdapterCPDS*_ I have no choice but to configure that quite often
> a query will be sent to the database to check if the connection is valid.
> In _*org.apache.commons.dbcp2.cpdsadapter.ConnectionImpl*_ everything is
> prepared: SQLExceptions in each method lead to a call to
> _*handleException()*_. Unluckily ConnectionImpl does not implement this
> method (and the parent class
> _*org.apache.commons.dbcp2.DelegatingConnection*_ does not do anything but
> throw the SQLException).
> The connection pool that is implemented by _*HikariCP*_ checks the
> SQLExceptions; "fatal" Exceptions are:
> SQLException.getSQLState() starting with
> _*08*_
> or returning one of
> _*0A000*_
> _*57P01*_
> _*57P02*_
> _*57P03*_
> _*01002*_
> _*JZ0C0*_
> _*JZ0C1*_
> SQLException.getErrorCode() returning one of
> _*500150*_
> _*2399*_
> and _*SQLTimeoutException*_. (Moreover HikariCP calls
> SQLException.getNextException() for up to 10 times and checks again.)
> Postgres (pgjdbc's _*org.postgresql.ds.PGPooledConnection*_ and also
> pgjdbc-ng's _*com.impossibl.postgres.jdbc.PGPooledConnection*_) fatal
> SQLExceptions are the ones where getSQLState() starts with
> _*08*_
> _*53*_
> _*58*_
> _*60*_
> _*99*_
> _*F0*_
> _*XX*_
> or getSQLState() is equal to
> _*57P01*_
> _*57P02*_
> _*57P03*_
> I would be happy with something like HikariCP's solution but it would be
> really fantastic if I could specify the check method.
>
> Die Lösung von HikariCP würde mir schon reichen, aber ganz besonders toll
> wäre natürlich, wenn man eine Prüfmethode für fatale SQLExceptions angeben
> könnte.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
