Transaction Processing with Queuing: A Solution for Direct TP Limitations, Slides of Fundamentals of E-Commerce

Download Transaction Processing with Queuing: A Solution for Direct TP Limitations and more Slides Fundamentals of E-Commerce in PDF only on Docsity!

9. Queued Transaction

Processing

Transaction Processing

Outline

1. Introduction2. Transactional Semantics3. Queue ManagerAppendices

A. MarshalingB. Multi-transaction Requests (workflow)C. (Appendix) Microsoft Message Queue

Persistent Queuing

Queuing - controlling work requests by movingthem through persistent transactional queues

• Benefits of queuing
  • client can send a request to an unavailable server– server can send a reply to an unavailable client– since the queue is persistent, a client can (in principle)

find out the state of a request

• can dequeue requests based on priority– can have many servers feed off a single queue

Client

Server

Enqueue

Dequeue

Other Benefits

Queue manager as a protocol gateway^ –

need to support multiple protocols in just one systemenvironment

can be a trusted client of other systems to bridgesecurity barriers

Explicit traffic control, without message loss

Safe place to do message translation betweenapplication formats

Transaction Semantics

Server View (cont’d)

Server program is usually a workflow controller

It functions as a dispatcher to^ –

get a request,

call the appropriate transaction server, and

return the reply to the client.

Abort-count limit and error queue to deal withrequests that repeatedly lead to an abortedtransaction

Transaction Semantics - Client View

Client runs one transaction to enqueue a requestand a second transaction to dequeue the reply Txn1: Startget inputconstruct requestEnqueue(Request, Q1)Commit Txn3: Start

Dequeue(Reply, Q2)decode replyprocess output Commit

Q1 Q

Txn2: Start

Dequeue(Req, Q1)process request ReqEnqueue(Reply, Q2) Commit

Client Recovery

If a client times out waiting for a reply, it candetermine the state of the request from the queues^ –

request is in Q1, reply is in Q2, or request is executing

Assume each request has a globally unique ID

If client fails and then recovers, a request could bein one of 4 states:^ –

A. Txn1 didn’t commit – no message in either queue.

B. Txn1 committed but server’s Txn2 did not –request is either in request queue or being processed

C. Txn2 committed but Txn3 did not – reply is in thereply queue

D. Txn3 committed – no message in either queue