Synchronizing Access to Transaction Objects

Synchronizing Access to Transaction Objects

The server agent maintains a number of objects on behalf of the application. In many situations, an application may want to access these objects from multiple threads. To guarantee safe access, the applications need to participate in a predefined resource locking scheme.

The server agent itself guarantees that no two threads will simultaneously execute separate handlers for messages belonging to the same transaction. It does this by serializing the message stream of each transaction internally, according to the order in which the messages were received. The server agent also acquires and releases all appropriate transaction locks. Therefore, if an application consists only of message handlers (it is strictly an MSPL script, or does not execute any code outside of dispatch handling methods), synchronization is handled entirely by the server agent and no specific implementation is needed within the application itself.

On the other hand, if applications queue internal work items that are serviced asynchronously, they must be aware of the locks implemented by the class library. The server agent still handles the acquisition and release of all locks for message handler calls, and applications need to synchronize with the server agent only when they are not executing message handlers for the transaction objects.

All objects related to a server transaction share a common lock. For a forking proxy, all of the branch client transactions share this common locked space with the original server transaction. Any application that references an object within this common space outside of the dispatch handler should lock it first. The reference to this common space is obtained from the Transaction.SyncRoot property on the respective ClientTransaction or ServerTransaction instance.