An error occurred fetching the project authors.
  1. 15 Jun, 2001 1 commit
    • Barry Warsaw's avatar
      checkHistoryAfterVersionCommit(), checkHistoryAfterVersionAbort(): · 904f8975
      Barry Warsaw authored
      After consultation with Jim, we agreed that Full's behavior vis object
      serial numbers after a version commit/abort are correct.  The new
      revision should get the serial number of the transaction that did the
      commit/abort.
      
      FileStorage is actually broken here; the new revision gets the same
      serial number as the last in-version revision.  However, the way the
      tests are written, it works for either storage, so I'm just updating
      some comments to explain the situation.
      
      Note: Jim also explained that history()'s "version" argument should be
      ignored.  Doesn't make much difference to these tests though.
      904f8975
  2. 14 Jun, 2001 6 commits
  3. 11 Jun, 2001 1 commit
  4. 08 Jun, 2001 1 commit
  5. 05 Jun, 2001 2 commits
  6. 04 Jun, 2001 3 commits
  7. 01 Jun, 2001 4 commits
  8. 31 May, 2001 1 commit
  9. 30 May, 2001 2 commits
  10. 23 May, 2001 2 commits
  11. 22 May, 2001 6 commits
    • Jeremy Hylton's avatar
      Remove many unused default argument definitions used as speed optimizations. · 7b3ca9e6
      Jeremy Hylton authored
      Many methods had default arguments that were used to bind a global or
      builtin name, like type, None, or type(''), as a local name.  In many
      cases, the names bound were not referenced in the method body
      (presumably they used to be referenced).
      
      commit_sub(): In this one case, delete the default arg anyway, because
          it's only used once.
      7b3ca9e6
    • Jeremy Hylton's avatar
      bb3bc4b7
    • Jeremy Hylton's avatar
      Remove invalidateMany(), which is not used anywhere. · 68d55d8f
      Jeremy Hylton authored
      The same effect can be achieved by:
      db.begin_invalidation()
      for oid in oids_to_invalidate:
          db.invalidate(oid)
      db.finish_invalidation()
      68d55d8f
    • Jeremy Hylton's avatar
      Cleanup of callback handling and tpc_vote(). · 54656f3d
      Jeremy Hylton authored
      There are two kinds of callbacks, commit actions and close actions.
      It is assumed that the use of these callbacks is infrequent.  As a
      result, the implementation used tuples defined as class attributes to
      avoid creation of instance variables to hold callbacks in the common
      case.  This implementation is complicated because tuples are
      immutable.  Unfortunately, the instance variables were actually
      created anyway in tpc_abort() and tpc_vote().
      
      This implementation changes the class attributes __onCloseCallbacks
      and __onCommitCallbacks to default to None.  If a callback is
      registered with an instance, a list is bound to an instance attribute
      of the same name.  When the transaction commits or aborts, the
      instance attribute is deleted.
      
      tpc_vote(): Remove the default arguments since they are unused in the
      body of the method.
      54656f3d
    • Jeremy Hylton's avatar
      tearDown(): Call delStorage() to clean up. · 6665dd6a
      Jeremy Hylton authored
      6665dd6a
    • Jeremy Hylton's avatar
      Add __closed attribute to asyncRPC object. · e56f46e7
      Jeremy Hylton authored
      __init__(): __closed = 0
      connect(): In connecting thread, don't continue if __closed is true.
      close(): __closed = 1
      e56f46e7
  12. 21 May, 2001 2 commits
    • Jeremy Hylton's avatar
      Fix deadlock problem reported by John D. Heintz. · 30e6b67a
      Jeremy Hylton authored
      If one thread was committing a transaction and another thread was
      opening a new DB connection, deadlock could occur.  The cause of the
      deadlock is that tpc_finish() acquires the storage and db locks in a
      different order than DB.open().  As a result, if each starts at the
      same time and gets one of the two locks it needs, the system will be
      deadlocked.
      
      The solution is to enforce a consistent locking order.  If a thread is
      going to hold the DB lock and the storage lock, it MUST acquire the DB
      lock first.  This patch implements that locking order for the
      invalidation in tpc_finish().
      
      The DB object gets methods called begin_invalidation() and
      finish_invalidation() that acquire and release the DB lock
      respectively.  Before the Connection calls tpc_finish() on the
      storage, it calls begin_invalidation().  This guarantees that the DB
      acquired before the storage lock.
      
      When the invalidation phase is over, the Connection calls
      end_invalidation() to release the DB lock.  This is an optimization.
      It could wait until tpc_finish() returns, but we know that the DB will
      not be used again for the rest of the tpc_finish() and tpc_finish()
      could take a long time.
      
      Specific changes:
      
      DB.py
      begin_invalidation(): Added.
      finish_invalidation(): Added.
      invalidate(): Remove locking.
      invalidateMany(): Add comment about how it should be used.
      
      Connection.py
      tpc_finish(): Don't pass second argument to storage's tpc_finish()
          when committing a transaction with no data.  Add call to
          begin_invalidation() before calling storage's tpc_finish().
      _invalidate_sub(): Remove empty, unnecessary method.
      _invalidating_invalidating(): Add call to finish_invalidation() after
          last call to DB's invalidate().
      30e6b67a
    • Evan Simpson's avatar
      Fixed assorted typos (Collector #218) · 4fc9694d
      Evan Simpson authored
      4fc9694d
  13. 20 May, 2001 2 commits
  14. 18 May, 2001 1 commit
  15. 17 May, 2001 1 commit
  16. 16 May, 2001 1 commit
  17. 14 May, 2001 1 commit
    • Jeremy Hylton's avatar
      Fix get_info() so that it copes if the storage doesn't define a · 65391a99
      Jeremy Hylton authored
      "supportsTransactionalUndo()" method.
      
      XXX untested
      
      XXX This mechanism for feature evolutional doesn't seem right, because
      it because a morass of backwards compatibility issues.  I'd rather see
      the test by one of presence/absence of an attribute or a base class.
      65391a99
  18. 10 May, 2001 3 commits