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.
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. Regards Ben