COM & .NET Component Services

Activities and Transactions

Transactional objects also allow access to them by only one client at a time. Synchronization is required to prevent the case in which one client on one thread tries to commit a transaction while another client on a second thread tries to abort it. As a result, every transaction should have a synchronization lock associated with it.

On the other hand, having more than one lock in a given transaction is undesirable—spinning off a new activity for an object that is added to an existing transaction means always paying for the overhead for checking the activity lock before accessing the object. That check is redundant because no two causalities are allowed in the same transaction anyway. In fact, when an object requires a new transaction, it could still reuse the same causality lock of its creator and allow the activity to flow into the new transaction. COM+ therefore enforces the fact that a given transaction can only be part of one activity (note that an activity can still host multiple transactions).

In addition, as discussed in Chapter 4, transactional objects always use JITA (COM+ automatically enables JITA for a transactional object). The use of JITA is only optional for nontransactional objects. Table 5-2 summarizes the synchronization values as a product of the transaction and JITA setting. Note that the only case when a transactional component can start a new activity is when that component is also configured to be the root of a new transaction. ...