Without going much deeper into the way zope uses database connections.

Wouldn't MySQL:Ping solve the reconnect Problem.
That's what I used in my old C++ projects.
Some kind of "ensureConnected" at the right place.


Jim Washington wrote:
> 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.
> Hi, Florent
> 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.
> -Jim Washington


Jürgen Kartnaller   mailto:juergen_at_kartnaller.at

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to