Transactional Object Life Cycle
If a transaction aborts, the intermediate and potentially inconsistent state of the system should be rolled back to ensure consistency. The system state is the data in the resource managers; it also consists of the state of all the objects that took part in the transaction. An object’s state is the data members it holds. If the object participated in an aborted transaction, then that object’s state should be purged too. The object is not allowed to maintain that state, since it is the product of activities that were rolled back.
The problem is that once a transaction ends, even if the object votes to commit, it does not know whether that transaction will actually commit. The DTC still has to collect all the resource managers’ votes, conduct the first phase of the two-phase commit protocol, and verify that all of the resource managers vote to commit the transaction. While this process takes place, the object must not accept any new client calls (as part of a new transaction) because the object would act on a system state that may roll back, which would jeopardize consistency and isolation.
To enforce consistency and isolation, once a transaction ends, regardless of its outcome, COM+ releases all the objects that took part in it. COM+ does not count on objects’ having the discipline or knowledge to do the right thing. Besides, even with good intentions, how would the objects know exactly what part of their state to purge?
However, even though the objects ...