Hello Tim Peters,
Friday, October 21, 2005, 11:08:28 PM, you wrote:
TP> Heh. Is there a secret agenda here, or is that line an elaborate way to
TP> spell "time.sleep(random())"?
yes, this is an elaborate way :)). Do you think that use "time.sleep" is more
correct way to freeze the thread?
TP> All ZODBs before 3.3 work that way. As an extreme example, if one of your
TP> threads never modifies a persistent object, it will never see changes made
TP> by other threads.
Is this mean that i explicitly must call scheduler._p_changed = 1
got the lastest states of the objects?
TP> This is the only material change, right (you moved this line into the loop)?
Yes, Tim, You are always right :))).
TP> It doesn't actually create a new Connection. When a Connection is closed,
TP> it doesn't really go away. It's added to a pool of available Connections
TP> maintained by the DB object; it doesn't even lose its memory cache.
I know about a pool of the available connections, but is it correct to have
not-closed connection for a long time? I.e. is it obligatory to return the
connection to the pool?
I have a question about the pool, under heavy load Zope have 4 connections to
zodb, + 1 connection from scheduler, and each scheduler element runs in
separate thread ( this needed for runs elements in identical times ).
And when 2 scheduler elements runs with heavy load from ZServer, i have
connections. From this point the Zope behave the uncorrectly ( appeared slow
speed, disappeared answers from server ). I try to place following code in my
from Zope import DB
DB.setPoolSize( 15 )
But this isn`t helped. i added some 'print's in Connection.py, and this
'print's show 2 numbers of the pool size. one number is 15, the second is
But i don`t know why '7' is still a pool size. So i replace number 7 to 15 in
Another problem that I have not-closed connections which i knew should be
closed for a some time ago. But i think this is problem of my code :)),
because usually connection closed by the REQUEST.close method, which placed
in finally section in ZPublisher.Publish.publish_module function. But when
catched the ConflictError, REQUEST closed in ZPublisher.Publish.publish
function too. And i didn`t find the code where the connection is reopened,
somewhere in the ZODB.ZApplication module.
TP> Anyway, one thing (re)open'ing a Connection does is process invalidation
TP> messages, regardless of whether any objects from the Connection have been
TP> modified, so that (re)opening appears to fix your problem is consistent with
TP> the hope that calling Connection.sync() could fix your problem too.
As i understand i must explicitly call the app._p_jar.sync() method in the
begining of each iteration of my infinite loop.
English is not my native laguage, and very sorry for my mistakes and typos
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org