[Zope3-dev] rdb: Disappearing Connection

[Jim Washington]

Christian Theune wrote:

>Am Dienstag, den 13.12.2005, 16:32 -0500 schrieb Jim Washington:
>  
>
>>Christian Theune wrote:
>>
>>    
>>
>>>Well. First, the error would be something like an OperationalError (or
>>>similar). Hmm. Not too distinguishable. Ideally we could:
>>>
>>> 
>>>
>>>      
>>>
>>>- differentiate this kind of error from other OperationalErrors (like a
>>>syntax error in your query)
>>> 
>>>
>>>      
>>>
>>The error in the traceback is
>>
>>_mysql_exceptions.OperationalError: (2006, 'MySQL server has gone away')
>>
>>    
>>
>>>- delete the _v_connection
>>>- restart the transaction
>>>
>>>Otherwise you might start over within a transaction that is out ouf sync
>>>with the state of the mysql database.
>>>      
>>>
>
>  
>
>>Good point. Though, this particular error is about idleness, so I would 
>>think it unlikely that one would be resuming an 8-hour-old transaction. 
>>Could that happen?
>>    
>>
>
>Sure. If I'd force it. But we can eventually ignore that with some good
>faith for a moment.
>
>That's a valid point. Additionally, IIRC this is a client message, not a
>server message. The server closes the connection much earlier but the
>client doesn't notice, as the client libraries are very very lazy.
>
>That means you could just purge the connection and create a new one.
>
>Still, we're not 100% sure that nothing was written to the connection
>that is now silently assumed of having been saved whereas it isn't.
>
>  
>
Yup.  Let's not kill it unless really necessary.

What seems to work for me for 
mysqldbda.adapter.MySQLdbAdapter.isConnected() looks like

    def isConnected(self):
        """exercise the connection to assure it is really there"""
        try:
            self._v_connection.conn.cursor().execute('SELECT 1')
        except:
            return False
        return True

It's a bare except, but the method returns False in any case where 
_v_connection is not listening as an SQL connection, which is exactly 
what we want to check.  Asking for conn.cursor() instead of 
_v_connection.cursor() gets around transactionality that should not be 
invoked here.

I'll declare success for now, and move on.  It's hopefully a temporary 
work-around.

-Jim Washington