COM+ transactions flow downward from the transaction root, as you have seen in Chapter 4. New objects created during the transaction take part in their creator’s transaction or are placed in a transaction of their own, according to their transaction configuration.
If the publisher takes part in a transaction, it is recommended that the subscribers participate in the publisher’s transaction. But how would the transaction be propagated by the publisher to the subscriber if the publisher does not create the subscriber directly?
To propagate the publisher’s transaction to the subscriber, you should configure the event class to support or require transactions. Like any other COM+ component, the event class has a Transaction tab that applies to the COM+ synthesized implementation.
Adding the event class to your transaction will not affect the
transaction voting result; in any COM+ context the consistency bit is
set by default to TRUE and the COM+-provided
implementation of the event class does not change that bit. You also
need to configure the (persistent) subscriber component to support
transactions. Now the subscriber takes part in the publisher’s
transaction and it can abort the publisher’s transaction or
vote to commit it.
There is one more thing you should keep in mind when mixing COM+ events and transactions: Do not configure the event class to require a new transaction. This causes the subscriber to take part in a separate transaction, the one initiated by the event class (see Figure 9-19).
Figure 9-19. Configuring the event class to require new transaction results in a separate transaction for the persistent subscriber
If the publisher’s transaction is aborted, the subscriber’s transaction can still commit successfully, which may involve changes to the database and other persistent changes to your system state. Nobody tells the subscriber to roll back those changes, despite the fact that the event that triggered the changes is fired from a transaction that aborts.
In addition, when the publisher tries again, the event may be fired once more, leaving the subscriber in an inconsistent state.
Similarly, avoid configuring any persistent subscriber’s transaction setting to Requires New and do not mix nontransactional subscribers with transactional ones; such practices may introduce unwelcome side effects when the publisher’s transaction is aborted (see Figure 9-20).
Transient subscribers are already instantiated when the event is fired and may be part of their creator’s transaction. I can only recommend being mindful when combining transient subscriptions with a transactional publisher because you may end up with the same inconsistencies mentioned in the previous section.
In particular, transient subscribers should not abort their client/creator’s transaction as a response to a publisher’s event, an event that may have been fired from within another transaction.
The problems that arise when you combine transient subscribers and publisher transactions are typical of passing object references across transaction boundarie. The object does not know whether it is allowed to abort the transaction or not (as discussed in Chapter 4).