[Zope] Re: Global variables in ExternalMethod modules

[Tres Seaver]

Ben Last (Zope) wrote:
> Tres Seaver wrote:
> 
>> Persistent objects are held in per-thread caches;  module-level stuff is
>> ~ *not* part of that cache.  People sometimes fake out thread-level
>> caches by assigning "volatile" attributes to persistent objects
>> (attributes whose names start with '_v_');  the downside is that such
>> attributes go away whenever the persistent object is "ghostified", which
>> may occur at unpredictable times (e.g., at transaction or subtransaction
>> boundaries).
> 
> Thanks very much for this, Tres; much appreciated.
> I've sorted the problem out thus:
> Added a module called ThreadShared which provides a thread-local storage 
> dict, obtainable by any thread calling ThreadShared.getTLS()
> I've then used that to store the per-thread objects I wanted 
> (MySQLdb.Connection objects, primarily)
> This is working very well now from within ExternalMethods.

I am glad to hear that.

>> Remind me again what you need a per-thread cache for?  Could you
>> scribble on the REQUEST object instead?
> 
> As above; initially for MySQLdb.Connection objects (actually, we have a 
> class that wraps them to make us more db-independent).  I do also 
> scribble on the REQUEST object with a _v_ attribute because that makes 
> obtaining the per-thread connection somewhat faster as the request code 
> calls the various database methods.  But the connections need to persist 
> between requests (to save continual database re-connection), so I needed 
>  somewhere thread-local to store them.
> 
> We also have a large number of configuration settings that are read at 
> startup; I've just added code to cache these with the date and time they 
> were read, allowing the cached versions to be used until they expire and 
> are re-read.  The database load has been significantly reduced with all 
> of this.

OK.  You probably know this already, but ZMySQLDA provides a persistent 
object which has pretty much exactly the same semantics:  it holds all 
the configuration data for the connection, and is responsible for 
holding open the actual connection across requests.  Because it is 
persistent, you end up (on a busy site) with as many open connections as 
you have worker threads.  I don't know what made that object unsuitable 
for your needs, but almost all Zope RDBMS adapters work the same way.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com