Florent Guillaume wrote:
Jim Washington wrote:
Spelunking a bit in the code,
zope.app.rdb.ZopeDatabaseAdapter.isConnected() looks at whether
_v_connection is present, not whether the connection is actually
alive. If we fix this here, isConnected() perhaps should handle the
case where the connection might be reaped by the back end db.
Frankly anything that uses _v_ attributes is asking for trouble
because it relies on low level behaviour of the ZODB and persistence
mechanisms. They can disappear at unpredictable times. Avoid them.
In this case, it is not particulary a problem if the _v_ attribute is
not there. It gets recreated if it does not exist. It is designed this
way so that different zope threads get separate rdb connections, which
is good. The problem here is false positives, where the _v_ attribute
exists, but the connection it promises has been silently expired and
disconnected by the MySQL server.
I was thinking of a check in isConnected() by making a cursor then
"try"ing executing "select 1" and return True if it does not raise the
exception. But that would be bad because it ~doubles the number of
requests to the SQL server. Perhaps not smart.
And, I've thought about a cron-like utility to ping the connection, but
now that I mention threads, that might be a non-solution if a broken
connection is in a different thread than the one contacted.
Zope3-dev mailing list