Why OO Developers May Hate Microsoft Transaction Server

Object-oriented technology permeates application development today. Like the spread of Islam a thousand years ago, the religion of objects has traveled across the globe making converts out of most developers. Even those who don't count themselves among the faithful must still cope with objects since virtually every modern language and tool requires using them.

A key tenet of the object faith is that each object instance encapsulates methods and state. An object representing a bank account, for example, has methods that allow its user to credit and debit funds to the account, and a state representing the account's balance. To work with a particular account, client code can create an instance of this object in memory, have that object initialize its state by reading the correct account balance from disk, call the methods of the object as needed to modify its state, then somehow save that state back to disk. The object and its state hang around until the client indicates that it's through using them. No matter how many method calls the client makes on this object, that state will still be there.

Now think about building scalable server applications using objects. Suppose hundreds or thousands of clients are using a single application to access various bank accounts simultaneously. Does the approach described above still make sense?

The answer, generally, is no. Allowing an object to maintain its state across a series of method calls from its client demands that the object take up space in memory the whole time. Even worse, the object is very likely holding on to a connection to some database. With many objects trying to access data at once, database connections can be in short supply. Allowing each object to hang on to its own connection can greatly limit an application's scalability. Each object also uses a thread, another potentially scarce resource in the server. If the human user of this application has, say, gone to lunch, an object could needlessly take up these valuable resources for a good long time.

A much more scalable solution is to force every object to release its state frequently, with the best definition of frequently being after every method call. This means a client can make multiple method calls to what looks to it like the same object, yet have that object's state destroyed after each call. To a true believer in objects, this is heresy.

To a CICS programmer, however, this is normal. Everybody who builds scalable, transaction-oriented applications knows that you can't maintain lots of per-user state across requests and still handle a large number of simultaneous clients. So combining objects with scalable, transaction-oriented applications leads to a dilemma—you can't be scalable and still use conventional objects.

The Microsoft Transaction Server faces exactly this problem. While MTS does require building applications using COM objects, it was created by diehard transaction processing people. Something had to give, and the conventional view of objects lost. In MTS a transactional object cannot maintain its state for more than 60 seconds -- actually, this is a default value that can be changed, but doing so is almost always a bad idea. In fact, the great majority of MTS objects have their state destroyed after every method call.

This makes those objects much more scalable, but it also makes them quite unlike traditional objects. I've heard howls of protest from the object faithful about this. Bitter complaints about the damage MTS does to the object paradigm. There's only one reasonable response to these people: Get over it. This is about technology, not religion. Years of experience show the value of this so-called "stateless" model in building scalable, transaction-oriented applications. True, it doesn't exactly conform to the object faith of our fathers and mothers. It does, however, provide something much more important: the ability to build applications that make users happy.

Having said all this, there are still times -- although not all that many -- when it makes sense to maintain state in an object that's part of a transactional application. MTS's main technology competitor, Enterprise JavaBeans, allows this today, though there aren't many EJB products available right now. The next release of MTS, COM+, also will allow an object to maintain its state across a transaction boundary. Even with these options, however, the key message is the same: If the goal is building scalable applications, maintaining an object's state across multiple invocations of that object's methods is rarely a good thing. With apologies to the object faithful, that's just the way it is. -- David Chappell is principal of Chappell & Associates (Minneapolis), an education and consulting firm. Contact him at david@chappellassoc.com.