1. 31 Aug, 2005 1 commit
  2. 30 Aug, 2005 2 commits
  3. 29 Aug, 2005 2 commits
  4. 26 Aug, 2005 5 commits
  5. 25 Aug, 2005 1 commit
    • Tim Peters's avatar
      Merge rev 38093 from 3.4 branch. · 7dc0787a
      Tim Peters authored
      Comment out the undocumented method definitions in the
      storage interfaces.  It would be better to define &
      document them, but that takes time, and until time is
      available better not to pretend that they're all really
      part of "the" storage API.
      7dc0787a
  6. 24 Aug, 2005 3 commits
  7. 23 Aug, 2005 1 commit
  8. 13 Aug, 2005 2 commits
  9. 12 Aug, 2005 3 commits
  10. 11 Aug, 2005 4 commits
  11. 09 Aug, 2005 1 commit
  12. 08 Aug, 2005 3 commits
  13. 07 Aug, 2005 1 commit
    • Tim Peters's avatar
      Merge rev 37777 from 3.4 branch. · 8c0c3c66
      Tim Peters authored
      Part of Collector 1860 (the other part is in Zope).
      
      There's no possiblity of rollback here, so no need to insist that the
      data manager support rollbacks.
      
      8c0c3c66
  14. 04 Aug, 2005 3 commits
    • Tim Peters's avatar
      An internal 3.5.0a6 release. · 9f89d9b3
      Tim Peters authored
      9f89d9b3
    • Tim Peters's avatar
      Merge rev 37713 from 3.4 branch. · d6f61513
      Tim Peters authored
      Plug leaks in the ZEO client cache.
      
      ClientCache._evicted():  When deleting the last range of
      non-current tids for an oid, remove the list from the
      noncurrent dict instead of leaving an empty list sitting
      there forever.  This also required adjusting the side-
      effect dance in ClientCache._remove_noncurrent_revisions().
      
      FileCache._makeroom():  This was the major leak -- it
      neglected to remove an evicted object's Entry from the
      key2entry dict.
      d6f61513
    • Philipp von Weitershausen's avatar
      Merge the philikon-zeo-scripts branch: · 59e1bccc
      Philipp von Weitershausen authored
        move things around so that zeo scripts are installed for
        standalone zodb releases but not for zope releases
      59e1bccc
  15. 02 Aug, 2005 1 commit
  16. 01 Aug, 2005 2 commits
  17. 29 Jul, 2005 2 commits
    • Tim Peters's avatar
      Merge rev 37574 from 3.4 branch. · 8c081bef
      Tim Peters authored
      makeroom():  Simplify retrieve+del from filemap.
      8c081bef
    • Tim Peters's avatar
      Merge rev 37563 from 3.4 branch. · f47937f6
      Tim Peters authored
      Removed the `key2size` OIBTree.
      
      Maintaining this is a significant expense; the code didn't
      make real use of it; and every time I've tried to exploit it
      I've ended up with grossly too-large simulated hit rates.
      Would probably take another day to figure out exactly why that
      is, and the simulated rates are "good enough" now without it.
      f47937f6
  18. 26 Jul, 2005 3 commits
    • Tim Peters's avatar
      Merge 3.4.1b1 news. · df4c8dfd
      Tim Peters authored
      df4c8dfd
    • Tim Peters's avatar
      Merge rev 37435 from 3.4 branch. · 7bcf73f8
      Tim Peters authored
      More words; update examples w/ new output.
      7bcf73f8
    • Tim Peters's avatar
      Merge rev 37432 from 3.4 branch. · a138c76e
      Tim Peters authored
      The cache simulation seems good enough to be useful now,
      although the toy app I wrote to generate a 500MB trace
      file doesn't use MVCC in an essential way (some of the
      MVCC simulation code is nevertheless exercised, since
      an invalidation of current data in the presence of MVCC
      always creates a cache record for the newly non-current
      revision).
      
      Still puzzling over what to do when the trace file records
      a load hit but the simulated cache gets a miss.  The
      old simulation code seemed to assume that a store for the same
      oid would show up in the trace file next, and it could get
      the info it needed about the missing object from the store
      trace.  But that isn't true:  precisely because the load was
      a hit in the trace file, the object isn't going to be stored
      again "soon" in the trace file.
      
      Here are some actual-vs-simulated hit rate results, for a
      20MB cache, with a trace file covering about 9 million
      loads, over 3 ZEO client (re)starts:
      
      actual   simulated
      ------   ---------
        93.1        92.7
        79.8        79.0
        68.0        69.1
            
        81.4        81.1  overall
      
      Since the simulated hit rates are both higher and lower
      than the actual hit rates, that argues against a gross
      systematic bias in the simulation (although there may
      be several systematic biases in opposite directions).
      a138c76e