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
   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:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to