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
{{ message }}
This repository has been archived by the owner on Jan 29, 2020. It is now read-only.
I am using php for long running scripts as a RabbitMq message comsumer. Messages can have DB access implemented as ZF3 / zend-db Tablegateway. The DB connection used is PDO_MYSQL.
In case DB connection is killed (MYSQL_CONNECTION_TIMEOUT or other), AbstractTableGateway throws an error (HY000 - 2006 - MySQL server has gone away) when trying to execute a statement against the closed connection.
I expect that Tablegateway / Adapter / db Driver is smart enough to handle lost connection and reconnect or at least handle "unconnected" state and connect (again).
Code to reproduce the issue
use some Tablegateway connected via PDO_MYSQL in a long running loop
while the loop runs, go to the MySQL-Server and kill the connection manually
you will get "HY000 - 2006 - MySQL server has gone away" in Tablegateway / Adapter / db Driver.
Expected results
when the DB connection is lost the DB managing objects should be able to connect again to the DB again as they did initially.
Actual results
when the DB connection is lost the DB managing objects are not able to connect again. An error is thrown: "HY000 - 2006 - MySQL server has gone away" in Tablegateway / Adapter / db Driver.
The text was updated successfully, but these errors were encountered:
I am using php for long running scripts as a RabbitMq message comsumer. Messages can have DB access implemented as ZF3 / zend-db Tablegateway. The DB connection used is PDO_MYSQL.
In case DB connection is killed (MYSQL_CONNECTION_TIMEOUT or other), AbstractTableGateway throws an error (HY000 - 2006 - MySQL server has gone away) when trying to execute a statement against the closed connection.
I expect that Tablegateway / Adapter / db Driver is smart enough to handle lost connection and reconnect or at least handle "unconnected" state and connect (again).
Code to reproduce the issue
Expected results
when the DB connection is lost the DB managing objects should be able to connect again to the DB again as they did initially.
Actual results
The text was updated successfully, but these errors were encountered: