The code didn't allow a way of doing this without a lot of work. Instead: the 'dbh' attribute is now a method that delegates to DBIx::Connector's dbh method. Per the docs, ->dbh() "Returns the connection's database handle. It will use a an existing handle if there is one, if the process has not been forked or a new thread spawned, and if the database is pingable. Otherwise, it will instantiate, cache, and return a new handle." Then there is the matter of the 'handles' on dbh. I've used Package::Stash to insert proxy methods into the class when it is loaded.
Summary: Push daemon: use DBIx::Connector to retrieve dbh inside a txn_do() block → Ensure Bugzilla::DB always called DBIx::Connector->dbh for any DBI method
Summary: Ensure Bugzilla::DB always called DBIx::Connector->dbh for any DBI method → Ensure we always call DBIx::Connector->dbh before any DBI method
Before this patch, if the mysql server was to restart (for instance), you'd start getting errors like this: Bugzilla->dbh->do("select 2") Runtime error: DBD::mysql::db do failed: MySQL server has gone away [for Statement "select 2"] at (eval 697) line 17. And those errors would stay for the life of the request, because Bugzilla->dbh is caching the real dbh (in Bugzilla->dbh->dbh). After this patch, what happens while the server is down: Runtime error: DBI connect('host=220.127.116.11;database=bugs_bmo','bugs',...) failed: Can't connect to MySQL server on '18.104.22.168' (111) at /vagrant/local/lib/perl5/DBIx/Connector.pm line 32. And after the server returns: Bugzilla->dbh->do("select 2") # no error.
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.