[ZODB-Dev] question about connections
Victor Safronovich
vsafronovich at naumen.ru
Mon Oct 24 02:23:49 EDT 2005
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 to
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 >=7
connections. From this point the Zope behave the uncorrectly ( appeared slow
speed, disappeared answers from server ). I try to place following code in my
product:
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 7.
But i don`t know why '7' is still a pool size. So i replace number 7 to 15 in
DB.__init__ constructor.
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, i think
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 :(.
--
Best regards,
Victor Safronovich
NauMen.NauDoc.SoftwareDeveloper http://www.naumen.ru
More information about the ZODB-Dev
mailing list