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 _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev