• Jim Fulton's avatar
    Internal refactoring of the commit lock manager · f4bcea77
    Jim Fulton authored
    In working on the next iteration of the lock manager to provide
    object-level locking, I realized:
    
    - It was saner let all waiting try to get locks when locks are
      released, at least in the more complicated logic to follow.
    
    - We really do almost certianly want a multi-threaded server, even if
      it doesn't run faster (still an open question), because otherwise,
      big commits will completely block loads.
    
    - We don't really want to hold the lock-manager lock while calling the
      callback.  Again, this really only matters if we have a
      multi-threaded server, but it also feels like a matter of hygiene :)
    
    I decided to rework this branch:
    
    - Don't hold lock-manager internal lock when calling the callnack.
    
    - When releasing the lock, use call_soon_threadsafe to let all waiting
      have a chance to get the lock.
    
    - A little bit of factoring to DRY. (This factoring will be much more
      useful in the follow-on branch.
    
    This rework restores the workability of the thread-per-client model.
    f4bcea77
testConversionSupport.py 3.74 KB