TP-Lite vs. TP-Heavy

According to database advocates, simple database transactions with stored procedures are all the transaction management anyone requires. That's the "TP-Lite" philosophy. In contrast, advocates of TP (transaction processing) monitors extend the notion of transactions beyond data resources. TP monitors track the execution of functions on a single server or several servers. That's the "TP-Heavy" approach.

TP-Lite is to TP-Heavy as a bicycle is to a Harley-Davidson motorcycle. TP-Lite can best be defined by what it lacks. TP-Lite functions don't execute under global transaction control. There's no global supervisor and only primitive process management. TP-Lite server functions incorporate only a single resource mana ger (i.e., the local database), and they don't support any form of ACID (atomic, consistent, isolated, and durable) nesting. TP-Lite may be adequate for a number of purposes, but the missing ingredients are rarely mentioned in the database marketing literature.

Scope of the Commit

A TP-Lite stored procedure is written in a database vendor's proprietary procedural language (e.g., PL/SQL and Transact SQL) and is stored in the database. A stored procedure is a transactional unit, but it can't participate with other transactional units in a global transaction. It can't call another transaction and have it execute within the same transaction boundary. So you have to write large transactions that put everything within the scope of the commit, which doesn't help the cause of modularization or reuse.

In contrast, TP-Heavy procedures are written using standard procedural languages. For TP-Heavy, global transactions are second nature.

Managing Heterogeneous Resources

A TP-Lite stored procedure can commit transaction resources that are only on the vendor's database or resource manager. It cannot synchronize or commit work that is on a foreign (local or remote) database or resource manager.

TP-Heavy procedures can easily handle ACID updates on multiple heterogeneous resource managers within the scope of a single transaction.

Process Management

A TP-Lite stored procedure gets invoked, executed under ACID protection (within a single-phase commit), and can then be cached in memory for future reuse. That's about it.

In contrast, TP-Heavy processes are prestarted and managed as server pools. As the load on a server pool grows, more processes start automatically.

Server pools support priorities and other class-of-service attributes. Server processes are protected from one another. If a server process dies, it can be restarted, or the transaction can be reassigned to another server process in that class. The entire environment runs under the constant supervision of the TP monitor. The server pool concept helps the TP monitor understand what class of service is required for a particular group of functions. It's an intelligently managed environment.

Client/Server Invocation

The TP-Lite stored procedure invocation is extremely nonstandard. Vendors provide their own proprietary RPC (remote procedure call) invocation mechanism. The RPCs are not defined using an IDL (Interface Definition Language), and they're not integrated with global directory, security, and authentication services. The communications links are not automatically restarted, and they are not under transaction protection. In addition, TP-Lite does not support MOM (message-oriented middleware) or conversational exchanges.

In contrast, the TP-Heavy environment is open to different communications styles. The RPC can use DCE (Distributed Computing Environment) as its base. Queued TP (a common option in TP monitors) is reemergi ng with the new name MOM. Most TP monitor vendors also support APPC/CPI-C (Advanced Program-to-Program Communications).

Performance

TP-Lite stored procedures are faster than networked static or dynamic SQL. But they don't perform as well as TP-Heavy managed procedures, especially under heavy loads.

The TP monitor offloads the database server by multiplexing client requests. It acts as a funnel on top of whatever funnel the database may have already put in place. So the TP monitor helps with both scalability and performance. Significant cost savings can be achieved because fewer database resources are needed to support a given workload. The Standish Group says: "Today, virtually all standardized transaction processing benchmark results (e.g., TPC-A) are executed with a TP monitor managing the application services in front of a database."

The Bicycle or the Harley

TP-Lite is useful in situations where you're dealing with a single vendor's databa se and fewer than 50 users. It's ideal in these entry-level environments, because you have to deal with only one server component: the database. The TP-Lite vendors also understand how to market their wares--an important advantage.

However, TP-Heavy technology is critical to the future of client/server computing. TP monitors allow us to mix components in all sorts of wild combinations; at the same time, they guarantee that everything meshes like clockwork.