1) Updates to provider registrations may interrupt the flow of events from that
    provider, no matter how small the change.
2) Updates to binding parameters can interrupt the flow of events through the
    binding.
*3) Updates to class defintions shall be treated as deletions and creations. 
    Thus, changing a class definition will interrupt the flow of affected
    events. 
*4) In light of (3), we will not take on any atmicity obligations in terms of
    delivering events when registration-affecting changes are taking place. 
    Another justification for it is that since the database supports no 
    transactioning, we can retrieve different definitions for a class during 
    our compilation, placing the ESS into an inconsistent state.  There is no 
    solution to this short of ESS implementing transactioned view of the DB.

5? What are we going to do about class definitions changing while providers
    (say instance providers) are holding them?
6) Reentrancy: while an update is in progress, no participant of that update 
    may initiate another update that affects any of the objects affected by the
    first update.  ESS will detect and reject by recording the thread id in the
    locks.