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@zope.com Zope Corporation "Zope Dealers" http://www.zope.com