1. 11 Jun, 2016 4 commits
  2. 10 Jun, 2016 2 commits
  3. 09 Jun, 2016 2 commits
  4. 07 Jun, 2016 3 commits
    • Jim Fulton's avatar
      Fixed maxtid, copying value from ZEO. · baee84a6
      Jim Fulton authored
      Changed it to the value corresponding to the maximim *signed*
      big-endian 64-bit integer, because of LxBTrees.
      
      Note that this value isn't used anywhere in ZODB yet.
      
      Maybe it should be.
      baee84a6
    • Jim Fulton's avatar
      typo · 5bb8a810
      Jim Fulton authored
      5bb8a810
    • Jim Fulton's avatar
      Clear transaction syncs earlier · 7a75ba7a
      Jim Fulton authored
      To mitigate errors during tearDown.
      
      Lots of tests are sloppy about closing connection (because they could
      be), but storages tend to get closed and transactions aborted. This
      has the effedt of calling afterCompletion on connections which tries
      to call storage lastTransaction, which causes errors.
      7a75ba7a
  5. 06 Jun, 2016 3 commits
  6. 05 Jun, 2016 1 commit
  7. 31 May, 2016 1 commit
    • Jim Fulton's avatar
      Merge pull request #62 from... · 6fe36b98
      Jim Fulton authored
      Merge pull request #62 from zopefoundation/dont-depend-on-implementation-detail-in-tpc_finish-test-assertions
      
      Fixed a test that depended on some off behavior of tpc_finish in some…
      6fe36b98
  8. 30 May, 2016 1 commit
  9. 17 May, 2016 2 commits
  10. 12 May, 2016 1 commit
  11. 09 May, 2016 3 commits
  12. 05 May, 2016 5 commits
  13. 04 May, 2016 7 commits
    • Jim Fulton's avatar
      OK, copying loadBefore was the right fix to the checkPackLotsWhileWriting failure · d90a0243
      Jim Fulton authored
      Even though the previous commit otherwise made MVCCMappingStorage and
      IMVCCStorage handling better.
      d90a0243
    • Jim Fulton's avatar
      Better IMVCCStorage support · 2729f3a9
      Jim Fulton authored
      The previous commit, made in anger, made a test pass, but wasn't
      really the right fix.
      
      This commit fixes MVCCMappingStorage's loadBefore implementation by
      fixing handling of the internal _ltid variable so that it's updated
      during poll_invalidations.  This allowed the base class version of
      loadBefore to be used and, I'm 97% sure has the right semantics.
      Fixing this revealed a problem with the Connection changes.
      
      Fixed Connection.py to poll for invalidations before computing
      _txn_time by calling lastTransaction, so as to get a current value.
      We still apply invalidations after computing _txn_time, so that
      persistent classes can be loaded correctly when they are invalidated.
      This was accomplished by weaving _flush_invalidations into
      newTransaction.
      2729f3a9
    • Jim Fulton's avatar
      On Python 2 and Mac OS X, checkFlushAfterTruncate was failing. · 86e62dae
      Jim Fulton authored
      Changed to always empty the file pool.  I doubt that just flushing on
      Python 2 was much of an optimization, and ... Python 2. :)
      86e62dae
    • Jim Fulton's avatar
      When creating a "new_instance", copy loadBefore, as well s pack. · f2922e4c
      Jim Fulton authored
      This is needed because pack temporarily deletes data from the data
      structure that loadBefore reads.
      
      Note that in the new scheme of things, we avoid using load, but
      instead use loadBefore.  This we bypass the _data_snapshot
      shenanigans, which makes me think we aren't testing what we should be,
      but I have no confidence that the machinery in MVCCMappingStorage
      actually reflects anything meaningful.
      f2922e4c
    • Jim Fulton's avatar
      Removed debugging print · 69e78b3f
      Jim Fulton authored
      69e78b3f
    • Jim Fulton's avatar
      1b6f7156
    • Jim Fulton's avatar
      Simplify MVCC by determining transaction start time using lastTransaction. · 227953b9
      Jim Fulton authored
      This implements: https://github.com/zopefoundation/ZODB/issues/50
      
      Rather than watching invalidations, simply use 1 + the storages
      lastTransaction, which is equivalent to but much simpler than waiting
      for the first invalidation after a transaction starts.
      
      More importantly, it means we can always use loadBefore and get away
      from load.  We no longer have to worry about ordering of invalidations
      and load() results.
      
      Much thanks to NEO for pointing the way toward this simplification!
      
      Implementing this initially caused a deadlock, because DB.open()
      called Connection.open() while holding a database lock and
      Connection.open() now calls IStotage.lastTransaction(), which acquires a
      storage lock. (It's not clear that lastTransaction() really needs a
      storage lock.)  Meanwhile, IStotage.tpc_finish() calls a DB function
      that requires the DB lock while holding the storage lock.  Fixing this
      required moving the call to Connection.open() outside the region where
      the DB lock was held.
      
      To debug the problem above, I greatly improved lock-debugging
      support. Now all of the ZODB code imports Lock, RLock and Condition
      from ZODB.utils. If the DEBUG_LOCKING is set to a non-empty value,
      then these are wrapped in such a way that debugging information is
      printed as they are used. This made spotting the nature of the
      deadlock easier.
      
      Of course, a change this basic broke lots of tests. Most of the
      breakage arises from the fact that connections now call
      lastTransaction on storages at transaction boundaries.  Lots of tests
      didn't clean up databases and connections properly.  I fixed many
      tests, but ultimately gave up and added some extra cleanup code that
      violated transaction-manager underware (and the underware's privates)
      to clear transaction synchonizers in test setup and tear-down.  I plan
      to add a transaction manager API for this and to use it in a
      subsequent PR.
      
      This tests makes database and connection hygiene a bit more important,
      especially for tests, because a connection will continue to interact
      with storages if it isn't properly closed, which can lead to errors if
      the storage is closed.  I chose not to swallow these errors in
      Connection, choosing rather to clean up tests.
      
      The thread debugging and test changes make this PR larger than I would
      have liked. Apologies in advance to the reviewers.
      227953b9
  14. 29 Apr, 2016 2 commits
  15. 28 Apr, 2016 2 commits
  16. 27 Apr, 2016 1 commit