[Bernstein09] Section 4.2. The Queued Transaction Processing Model

4.2. The Queued Transaction Processing Model
Server’s View of Queuing
Let’slook at how the queued TP model works in the context of a transactionfrom a server’s perspective. As in our description of direct TP inprevious chapters, we will assume that each request is asking for justone transaction to be executed. In the queued TP model, the serverprogram starts a transaction and dequeues the next request from therequest queue (seeFigure 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.

Sincethese queues are transactional resources, if the transaction aborts,the dequeue operation that receives the request is undone, therebyreturning the input request to the request queue. If the abort happensat the very end, then the enqueue operation to the reply queue also isundone, thereby wiping out the reply from the reply queue. Therefore,whenever the client checks the queues, either the request is in therequest queue, the reply is in the reply queue, or the request can’t bechecked because it is currently being processed. In any case, there’snever any ambiguity as to the request’s state. It either has not yetbeen processed, is in the midst of being processed, or has beencompleted.
Client’s View of Queuing
InFigure 4.4we looked at the queues from the server’s viewpoint. Now let’s look atthe entire path from the client to the server in the queued TP model.In this model, each request executes three transaction programs (seeFigure 4.5).Transaction 1 (Submit Request) receives input from the user, constructsa request, enqueues that request onto the request queue, and thencommits. Then Transaction 2 (Execute Request) runs, just as describedinFigure 4.4:It starts a transaction, dequeues the request, processes the request,enqueues the reply, and commits. At this point, the request is gonefrom 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 theproper output format, delivers that output, and commits, thereby wipingout the reply from the reply queue.
Figure 4.5. Running a Request as Three Transactions. Theclient submits a request (Transaction 1), the server processes therequest and returns a reply (Transaction 2), and the client processesthe reply (Transaction 3).

Forexample, to run a debit transaction, the client runs a transaction thatenqueues a request on the request queue. The debit server runs atransaction that dequeues the request, debits the account, and enqueuesa reply that confirms the debit. Later, the client runs a transactionto dequeue the reply and print a receipt. By contrast, if direct TPwere used, the client would send the request directly to the server,and the server would send the reply directly to the client, all withinone transaction and without any queues in between.
InFigure 4.5the client pushes a request to the queue while the server pulls it fromthe queue. If desired, the server (Transaction 2) can be turned into apush 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” inFigure 4.5), and, after the latter finishes, commits.
Becausethe queues are now under transaction control, they have to be managedby a database system or some other resource manager that supportstransaction semantics. To optimize performance, TP systems often usea specialized queue manager that is tuned for the purpose. Today’stransactional middleware products typically provide an API to anexternal queued messaging system that supports transaction semantics.
Noticethat to run even a single request, the system executes threetransactions. The client transactions may be rather lightweight, astransactions go. For example, in the simple case ofFigure 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 ordinarydirect TP system in which each request runs as a single transaction.Not only are there two client transactions, but the server transactionhas two additional accesses to transactional resources—the request andreply queues. In return for this extra overhead, the system offers thebenefits that we talked about previously; that is, communication withunavailable servers and clients, load balancing across servers, andpriority-based scheduling.