21 lines
1.2 KiB
Plaintext
21 lines
1.2 KiB
Plaintext
|
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.
|