• Tim Peters's avatar
    Merge recent fixes from 3.4 branch. · f6dfdd6c
    Tim Peters authored
    Original checkin msgs follow:
    
    r30203 | jim | 2005-04-27 11:55:09 -0400 (Wed, 27 Apr 2005) | 2 lines
       M /ZODB/branches/3.4/src/transaction/_transaction.py
    
    Fixed stupid bug.
    
    r30200 | jim | 2005-04-27 07:20:56 -0400 (Wed, 27 Apr 2005) | 39 lines
       M /ZODB/branches/3.4/src/transaction/_transaction.py
    
    Changed the strategy for managing savepoints.  The requirements
    for savepoint management are:
    
    - All savepoints for a transaction should be invalidated when the
      transaction commits or aborts
    
    - If a savepoint is rolled back, then all savepoints after it within
      a transaction must be invalidated.
    
    We previously implemented these requirements by organizing transaction
    savepoints into a doubly linked list.  This was overkill.  We didn't
    have need for such fine-grained ordering.  This strategy had the
    disadvantage that it kept all savepoints around until the transaction
    ended.  Savepoints could be expensive to keep and it's possible that
    some applications could keep a lot of them.
    
    The new stragey is to:
    
    - Keep weak references to savepoints.  We can forget about savepoints
      that the application isn't using.  Any resources used by these
      savepoints can be freed.
    
    (We have to keep a strong reference to the last savepoint used for
      a subtransaction.)
    
    - We assign indexes to savepoints within a transaction.  When a
      savepoint is rolled back, in addition to invalidating that
      savepoint, we also invalidate savepoints with a higher index.
    
    A side effect of this change is that code using the savepoint API
    should interfere less with code using subtransactions.  Of course, we
    really need to phase out code that uses subtransactions.
    
    It is likely that we can leverage this change in strategy to speed
    creation of ZODB connection savepoints.  Creating a ZODB connection
    savepoint now requires copying the savepoint storage index.  This
    index could become large.  If applications aren't holding on to old
    savepoints, then it is possible that we could avoid this copy.
    
    f6dfdd6c
_transaction.py 24.6 KB