Holding State in Objects with Microsoft Transaction Server

Microsoft Corporation

June 1997

Abstract

Although there are many benefits to using stateless Microsoft® Transaction Server (MTS) objects, there are cases where holding state is desirable. This article provides some guidelines in deciding where state is held in your application.

Determining State

The following diagram shows a three-tier architecture:

Typically, the latency between tiers differs greatly. Calls between the presentation tier and business tier are often an order of magnitude slower than the business tier and data tier. As a result, held state is more costly when calling into the business tier.

However, it often makes sense to hold state within the transaction boundary itself. For example, the objects in the data tier may represent a complex join across many tables in separate databases. Reconstructing the data object state is potentially more costly than any resources held by those objects while they remain active.

Remember that objects lose state on transaction boundaries. If you need to hold state across transactions, use the Shared Property Manager or store the state in a database.

Example: Order-Entry Application

There are two separate issues when considering the effects of holding state in an application:

• Network round trips—More frequent network roundtrips and slower connections extend the lifetime of the called MTS object.
  
  
• Held resources—Holding state often means holding onto a resource, such as a database connection, and, potentially, locks on the database.

Consider the example of an online shopping application. The client chooses items from a catalog and submits an order. The order processing is handled by a business object, which in turn stores the order in a database (not shown).

One way of building the application is for the client to call an Order object, with each call adding or removing an item from the order:

This application has the following properties:

• Client maintains no state.
  
  
• Server maintains state across multiple calls.
  
  
• Many network round trips.
  
  
• High contention for resources. The database connection is held for the lifetime of the Order object. This is not a very scalable solution.

You could require that the client cache the items in an array or recordset:

This application has the following properties:

• Stateful client.
  
  
• Server is virtually stateless with one call to the server.
  
  
• Fewer network round trips.
  
  
• Less contention for resources. This is a scalable solution.

Concurrency

In addition to network bandwidth and resources, concurrency affects application performance. There are two types of concurrency:

• Pessimistic—The database locks the records being changed as soon as editing begins. The records are unlocked when all changes are complete. No two users can access the same record at the same time.
  
  
• Optimistic—The database locks the records being changed only when the changes are committed. Two users can access the same record at the same time, and the database must be able to reconcile (or simply reject) changed records that have been edited by multiple users prior to commit.

Implementing a server cache implies optimistic concurrency. The server does not have to hold locks on the database, thus freeing resources.

However, if there is high contention for the resource, pessimistic concurrency may be preferred. It is easier to reject a request to access a database and have the server try again than it is to reconcile data that is becoming out-of-date in a server cache with a rapidly changing database.