[Bernstein09] Section 4.2. The Queued Transaction Processing Model

4.2. The Queued Transaction Processing Model

Server’s View of Queuing

Let’s look at how the queued TP model works in the context of a transaction from a server’s perspective. As in our description of direct TP in previous chapters, we will assume that each request is asking for just one transaction to be executed. In the queued TP model, the server program starts a transaction and dequeues the next request from the request queue (see Figure 4.4). The server then does the work that the request is asking for, enqueues the reply to the reply queue, and commits.

Figure 4.4. Managing a Queued Request within a Transaction. The request is dequeued and the reply enqueued within a transaction. If the transaction aborts, the request isn’t lost.

Since these queues are transactional resources, if the transaction aborts, the dequeue operation that receives the request is undone, thereby returning the input request to the request queue. If the abort happens at the very end, then the enqueue operation to the reply queue also is undone, thereby wiping out the reply from the reply queue. Therefore, whenever the client checks the queues, either the request is in the request queue, the reply is in the reply queue, or the request can’t be checked because it is currently being processed. In any case, there’s never any ambiguity as to the request’s state. It either has not yet been processed, is in the midst of being processed, or has been completed.

Client’s View of Queuing

In Figure 4.4 we looked at the queues from the server’s viewpoint. Now let’s look at the entire path from the client to the server in the queued TP model. In this model, each request executes three transaction programs (see Figure 4.5). Transaction 1 (Submit Request) receives input from the user, constructs a request, enqueues that request onto the request queue, and then commits. Then Transaction 2 (Execute Request) runs, just as described in Figure 4.4: It starts a transaction, dequeues the request, processes the request, enqueues the reply, and commits. At this point, the request is gone from the request queue, and the reply is sitting in the reply queue. Now, Transaction 3 (Process Reply) runs: It starts a transaction, dequeues the reply from the reply queue, translates the reply into the proper output format, delivers that output, and commits, thereby wiping out the reply from the reply queue.

Figure 4.5. Running a Request as Three Transactions. The client submits a request (Transaction 1), the server processes the request and returns a reply (Transaction 2), and the client processes the reply (Transaction 3).

For example, to run a debit transaction, the client runs a transaction that enqueues a request on the request queue. The debit server runs a transaction that dequeues the request, debits the account, and enqueues a reply that confirms the debit. Later, the client runs a transaction to dequeue the reply and print a receipt. By contrast, if direct TP were used, the client would send the request directly to the server, and the server would send the reply directly to the client, all within one transaction and without any queues in between.

In Figure 4.5 the client pushes a request to the queue while the server pulls it from the queue. If desired, the server (Transaction 2) can be turned into a push model by adding a dispatcher component that starts a transaction, dequeues the request, calls the rest of the Transaction 2 code (i.e., starting with “process request” in Figure 4.5), and, after the latter finishes, commits.

Because the queues are now under transaction control, they have to be managed by a database system or some other resource manager that supports transaction semantics. To optimize performance, TP systems often use a specialized queue manager that is tuned for the purpose. Today’s transactional middleware products typically provide an API to an external queued messaging system that supports transaction semantics.

Notice that to run even a single request, the system executes three transactions. The client transactions may be rather lightweight, as transactions go. For example, in the simple case of Figure 4.5, they each do one access to a transactional resource, that is, a queue. But even so, queued TP uses more system resources than an ordinary direct TP system in which each request runs as a single transaction. Not only are there two client transactions, but the server transaction has two additional accesses to transactional resources—the request and reply queues. In return for this extra overhead, the system offers the benefits that we talked about previously; that is, communication with unavailable servers and clients, load balancing across servers, and priority-based scheduling.