as andy mentioned, _v_ volatile attributes are specific to a thread (well, technically there specific to the underlying zodb connection). they remain only as long as the object remains in memory/cache. there is no notice when object is evicted from cache/memory. the object returns to a ghost state, which has no instance state till its accessed again. if you really want global variables that exist for the lifetime of the server, use module level attributes, they are shared by all threads, you will need to do your own locking. -kapil On Thursday 15 August 2002 05:55 pm, Charlie Reiman wrote:
I've got a product that has a little pool of database connections. These are low level DCOracle2 objects, not Zope DB connections. These live in a hash table-like cache living in a volatile attribute of a persistent product.
Something like this:
myproduct _v_mycache conn1 conn2 conn3
The cache periodically reaps old connections. The product insures the cache exists before it uses it, as it is volatile and might not exist at any point in time. Here's my problem:
Occasionally, my _v_mycahce is empty when I didn't clear it. It looks like my product object gets dropped from memory, then reloaded, resulting in a missing cache. If this is true then what I need is an class or attribute that is persistent for the server lifetime. It looks like all I can get from Zope is permanent persistent objects or volatile objects.
So my questions are:
1) Can I put a trap somewhere on my object so I know when it gets purged or loaded? Just a simple "sys.stderr.write('loading\n')" would be enough to confirm my suspicions.
2) Is there a server-lifetime class of objects? Is there a workaround to get there? Can I force my object and its attributes to live in memory and not get purged until shutdown?
Thanks in advance. I think I can work around this with traditional coding kung-fu, but it'll be a pain. A solution like 'set this attribute to true' or 'subclass from twiddle' would make me really happy.
Charlie.