BNZTransactionalNotificationCenter
Abstract: The BNZTransactionalNotificationCenter is the base of the whole framework
The BNZTransactionalNotificationCenter is the base of the whole framework.
It keeps track of all the transactions on a system.
A reference to the notification center can be obtained by the statid defaultCenter method.
The BNZTransactionalNotificationCenter manages exactly zero or one transaction for each
thread. A transaction for the current thread can be obtained by calling currentTransaction.
This will return the current transaction for the thread of the caller. If no such
transaction exists, the BNZTransactionalNotificationCenter creates one (see also
currentTransactionCreateIfNotPresent:)
The BNZTransactionalNotificationCenter also offers the possibility to register
observers (through BNZObservation objects). Similar to the NSNotificationCenter,
such observers are informed when a certain event occurs
An event in this framework is: a BNZAtomicChange is contained in a committing transaction.
When a transaction is committed, all observers are collected that have interest in at least
one of the changes contained in the transaction. Then, depending on the current state of the
transaction (COMMITTING, COMMITTED, ROLLED_BACK), the observers receive the messages they
registered through the BNZObservation.
The "synchronization" of the transactions that want to commit is done in the clearToCommit:
method that is called by the BNZTransaction. This method blocks the thread of the calling
transaction until it is save to commit.
IMPORTANT NOTE FOR FUTURE WORK:
see documentation of BNTTransaction for more details about when
the commit is halted. However, there may still be issues with dirty reads during a commit.
Example:
1 Person firstname="Bob", lastname="Sinclair"
2 Change 1: "Bob" -> "Alice"
3 Change 2: "Sinclair" -> "Johnson"
4 Thread A is committing the transaction with the two changes.
5 While A is in the for-loop that iterates all changes and commits (applies) them individually: a Thread B steps in
6 Thread B may now read something like "Alice Sinclair", which is illegal and therefore a dirty read
I am not sure if this is currently possible and if yes, how to prevent this in an elegant manner. The
problem is:
Either: How to tell the system that the commit for-loop may not be interrupted by other threads
or: How to block getter-methods until the commit is finished.
The goal would be, of course, to do this with the least possible intrusion to the transactional objects
(i.e., the implementation of a getter of an object should be as easy as possible) without too much overhead
(putting locks everywhere is a bad idea:)
(Last Updated 8/31/2006)
HTML documentation generated by HeaderDoc