[PECOBLR-1655] Implemented the functionality of pool_pre_ping #53
[PECOBLR-1655] Implemented the functionality of pool_pre_ping #53msrathore-db wants to merge 7 commits intomainfrom
Conversation
… to see if the connection is alive. If not it'll recycle the session
|
@msrathore-db This maybe a better solution. |
…ing the default behaviour
Fix CI failures caused by incompatible newer poetry versions by pinning poetry to version 2.2.1 in all GitHub Actions workflows. This follows the same fix applied in databricks-sql-python PR #735. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Enhanced is_disconnect() to catch databricks.sql.exc.Error (base class) and detect "closed connection" errors. This fixes pool_pre_ping failing when attempting to ping a closed connection. The default do_ping() tries to create a cursor, which raises Error with message "Cannot create cursor from closed connection" on closed connections. Now properly detects this as a disconnect error. Fixes: - test_pool_pre_ping_with_closed_connection - test_is_disconnect_handles_runtime_errors Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
|
@msrathore-db Any ETA on this PR? We are seeing |
We should be able to get it merged and released this week. Thanks |
src/databricks/sqlalchemy/base.py
Outdated
| # This catches errors like "Cannot create cursor from closed connection" | ||
| if isinstance(e, Error): | ||
| error_msg = str(e).lower() | ||
| return "closed" in error_msg or "cannot create cursor" in error_msg |
There was a problem hiding this comment.
is having closed a definite case for closed connection? There can be error message like cannot be closed etc. Seems to be error prone.
There was a problem hiding this comment.
Modified to be precise after checking all error occurences in the python SQL connector. Thanks
| from databricks.sql.exc import InterfaceError, DatabaseError, Error | ||
|
|
||
| # InterfaceError: Client-side errors (e.g., connection already closed) | ||
| if isinstance(e, InterfaceError): |
There was a problem hiding this comment.
InterfaceError can also be raised for programming errors like invalid params. Will this be an expected behavior then?
There was a problem hiding this comment.
That's not the case with the current connector. All the interface errors are raised when connection is closed.
gopalldb
left a comment
There was a problem hiding this comment.
LG, minor comments on error handling
- InterfaceError: check for "closed" in message instead of blanket True - Add RequestError handling for transport/network-level disconnect errors - Add "unexpectedly closed server side" to DatabaseError disconnect checks - Keep base Error fallback with precise "closed connection"/"closed cursor" matching for older connector versions (v4.0.0-v4.0.5) that raise Error instead of InterfaceError - Expand tests to cover all connector error messages with exact code paths Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
447e1bf to
0145f62
Compare
Summary
Implements
is_disconnect()method to enable connection health checking and prevent "Invalid SessionHandle" errors when connections expire or are closed by the server.Closes #47
Problem
Users experienced
Invalid SessionHandleerrors when connections expired or were closed by the server. SQLAlchemy'spool_pre_ping=Truefeature wasn't working because the dialect didn'timplement
is_disconnect()to classify disconnect errors.When connections died (either before checkout or during query execution), SQLAlchemy couldn't determine if errors were due to disconnects, leaving dead connections in the pool and causing
repeated errors.
Solution
Implements
is_disconnect()method that classifies exceptions as disconnect errors, enabling both pessimistic and optimistic disconnect handling as described in SQLAlchemy's pooling documentation.