1. 12 Nov, 2002 5 commits
  2. 11 Nov, 2002 8 commits
  3. 09 Nov, 2002 5 commits
  4. 08 Nov, 2002 6 commits
    • Barry Warsaw's avatar
      We don't need this file now that BerkeleyConfig supports setting the · 9ac77874
      Barry Warsaw authored
      cache size, and other useful BerkeleyDB parameters.
      9ac77874
    • Barry Warsaw's avatar
    • Barry Warsaw's avatar
      BerkeleyConfig: Added `frequency', `packtime', and `classicpack' · 42aacd6f
      Barry Warsaw authored
      attributes for controlling autopack behavior.
      42aacd6f
    • Barry Warsaw's avatar
      Support for autopacking in a separate thread. BerkeleyConfig now has · 9efc9849
      Barry Warsaw authored
      three new configuration variables for controlling how autopacking
      works.  Basically, you set an autopack frequency, a "packtime" -- the
      point in the past you want to pack to -- and a counter for
      automatically doing a classic pack.
      
      Specific changes here include:
      
      _setupDBs(): If autopacking is enabled, create the autopacking thread
      object and get it started.
      
      close(): When shutting down the storage, we need to stop and join the
      autopacking thread, otherwise I think we have a high possibility of
      corrupting our database (requiring recovery).
      
      _dopack(): Add a flag for whether full gc should be done or not.
      That's about the only difference between classic pack and autopack
      (the latter does not do gc).
      
      autopack(): The method that the autopacking thread calls to start an
      autopack.  It takes a pack time with the same semantics as pack(), but
      it also takes a flag specifying whether to do garbage collection of
      unreachable objects or not.
      
      _Autopack: A derived class of threading.Thread to handing the
      background autopacking.
      9efc9849
    • Barry Warsaw's avatar
      A test of Full's autopacking feature. · d1e0435a
      Barry Warsaw authored
      d1e0435a
    • Barry Warsaw's avatar
      A new algorithm for packing which seems much more straightforward. · 27f80e8e
      Barry Warsaw authored
      Here's how it works:
      
      - On every store(), we write an entry to a objrev table containing the
        tuple of information (newserial, oid, oldserial).  We don't write
        this entry if the store is the first revision of an object on a new
        version.
      
        We do basically the same thing on restore() and transactionalUndo().
      
      - On an abortVersion(), we write two entries to the objrev table, one
        that has (newserial, oid, oldserial) -- which points to the old
        serial in the version, and (newserial, oid, nvserial) -- which
        points to the non-version revision of the version revision.
      
      - On commitVersion(), we do the same as abortVersion() except that we
        don't write the non-version data if we're committing to a different
        version.
      
      - Now, when we pack, all we need to do is cruise from the beginning of
        the objrev table until we find an entry with a newserial > packtime.
        If the oldserial is ZERO, it's an object creation event which we
        don't need to worry about because there's no previous revision.  But
        otherwise, we can delete the oid+oldserial revision because we know
        it's not current.  We do this, updating pickle refcounts and then
        collecting any objects that are left unreferenced.
      
      The cute thing is that autopacking will use the same algorithm.  The
      main difference between autopack and classic pack, is that the latter
      does a mark and sweep garbage collection phase after the normal objrev
      collection phase.  Also, this algorithm means autopack needs only
      three pieces of information:
      
      - How often the thread should run (e.g. once per hour)
      
      - How far in the past it should pack (e.g. pack to 4 hours ago).  We
        don't need a start time for the autopack window, because we'll
        always just start at the beginning of the objrev table.
      
      - How often should autopack also do a classic pack (e.g. do a classic
        pack once per day).
      
      Autopack isn't implemented in this checkin, but I believe it will be
      nearly trivial to add.  That comes next.
      27f80e8e
  5. 05 Nov, 2002 3 commits
  6. 04 Nov, 2002 2 commits
  7. 31 Oct, 2002 2 commits
  8. 30 Oct, 2002 1 commit
  9. 29 Oct, 2002 1 commit
  10. 28 Oct, 2002 1 commit
  11. 26 Oct, 2002 2 commits
  12. 24 Oct, 2002 1 commit
  13. 23 Oct, 2002 1 commit
  14. 22 Oct, 2002 2 commits