[Zope] Re: Global variables in ExternalMethod modules
tseaver at zope.com
Wed Feb 2 07:57:55 EST 2005
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
> 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 Seaver tseaver at zope.com
Zope Corporation "Zope Dealers" http://www.zope.com
More information about the Zope