[Zope-DB] How to do analysis? (was Re: Saga continues...)

[Matthew T. Kromer]

Dario Lopez-Kästen wrote:

>----- Original Message -----
>From: "Bo M. Maryniuck" <b.maryniuk at forbis.lt>
>  
>
>>On Thursday 02 October 2003 11:42, Dario Lopez-Kästen wrote:
>>    
>>
>>>What I cannot live with
>>>is Zope waiting for a response on a connection that was dropped for
>>>someunknown reason.
>>>      
>>>
>>The reason is: connection object is stored into volatile attribute to
>>be stored without pickling. When __setstate__() is called (and called
>>all the time) you call that object, if there is no such connection,
>>then self.connect(self._connection_string) called in Connection.py
>>(AFAIK).
>>    
>>
>
><snip rest of excellent explanation>
>
>I have one, really generic and slightly off-topic question: what do I need
>to do to do this kind of analysis and gather this kind of forensic data?
>
>I probably need to obtain some kind of Zope/Python Zen-hood, but I am a
>quick learner - I just don't know *where to start*.
>
>...maybe it is just a matter of reading of core code? I have tried to avoid
>digging too deep into the Zope core code, because I simply don't really have
>time to learn the inner-inner workings of Zope. However, we are doing more
>and more stuff with Zope and relying more and more on it - perhaps it is
>time to make time for deep deep understanding of Zope? So far I have tried
>to stay on the "advanced user, don't need to know too much" side of the
>fence... seems it is time to take the jump to the other side.
>
>Sincerely,
>
>/dario
>  
>

It is not at all easy to debug some of these things :(

For my part, from the RDBMS user's perspective, the way DCOracle2 handes 
the Zope layer is very far from the ideal.  It really wants some kind of 
connection manager object that is independant from the actual connection 
objects used by threads, and controls and manages state for those 
threads.  As Bo said, this kind of object is best instantiated at the 
module level and NOT as a persistant or thread-specific Zope object.   
There are a lot of gotchas with doing this, since objects that exist 
"outside" of Zope still need to do the right thing w.r.t. Zope 
transactions if they are used within the context of a transaction.

I am terribly time constrained and don't have any time to work on the DA 
side, unfortunately.  I am willing to put some extra support into the C 
layer if someone is willing to work on upper layers, ie 
connection.status() or cursor.status() to try to figure out if the 
connection is still alive.

-- 
Matt Kromer
Zope Corporation  http://www.zope.com/