[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