You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The state codes which should be treated as connection errors are:
"JZ0C0" - Connection is already closed
"JZ0C1" - An IOException occurred which closed the connection
Unfortunately the JConnect driver chains JZ0C1 inside a JZ006 exception - as documented by the pdf above. I have also experienced behavior where JZ0C0 has been chained inside a JZ006, although this is not mentioned by the spec. In spite of the description given, JZ0C0 can appear without invoking connection.close() explicitly.
The spec suggests that if a JZ006 occurs without any chained exceptions that the connection is still in a usable state - although I have never seen this particular scenario occur in my (limited) usage of the driver to date.
This suggests that a robust implementation would be to add both JZ0C0 and JZ0C1 to the SQL_ERRORS set and then change the behavior of checkException to check both sqle.sqlState and sqle.getNextException.sqlState (when defined) against the error list. JZ006 should not be treated as a connection error.
The text was updated successfully, but these errors were encountered:
Added Sybase exception detection. Note the disconnection detection in exception handling is "optional" and I have considered removing it from HikariCP in the past. Connections are tested on checkout from the pool, which usually covers disconnection detection. Detecting it early is merely an optimization that avoids the test query.
ConnectionProxy.java implements a SQLState check to determine if a connection is in a broken state.
The current implementation supports the SQL 2003 standard and Postgres specific codes.
The Sybase JConnect driver has its own proprietary SQL state codes which are documented in the programmers manual available at http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc39001.0700/pdf/prjdbc0700.pdf
The state codes which should be treated as connection errors are:
"JZ0C0" - Connection is already closed
"JZ0C1" - An IOException occurred which closed the connection
Unfortunately the JConnect driver chains JZ0C1 inside a JZ006 exception - as documented by the pdf above. I have also experienced behavior where JZ0C0 has been chained inside a JZ006, although this is not mentioned by the spec. In spite of the description given, JZ0C0 can appear without invoking connection.close() explicitly.
The spec suggests that if a JZ006 occurs without any chained exceptions that the connection is still in a usable state - although I have never seen this particular scenario occur in my (limited) usage of the driver to date.
This suggests that a robust implementation would be to add both JZ0C0 and JZ0C1 to the SQL_ERRORS set and then change the behavior of checkException to check both sqle.sqlState and sqle.getNextException.sqlState (when defined) against the error list. JZ006 should not be treated as a connection error.
The text was updated successfully, but these errors were encountered: