Advanced Transaction Processing
Advanced Transaction Processing
Processing
Transaction-Processing Monitors
Transactional Workflows
High-Performance Transaction Systems
z Main memory databases
z Real-Time Transaction Systems
Long-Duration Transactions
Transaction management in multidatabase systems
Database System Concepts - 6th Edition 26.2 ©Silberschatz, Korth and Sudarshan
Transaction Processing Monitors
TP monitors initially developed as multithreaded servers to support
large numbers of terminals from a single process.
Provide infrastructure for building and administering complex transaction
processing systems with a large number of clients and multiple servers.
Provide services such as:
z Presentation facilities to simplify creating user interfaces
z Persistent queuing of client requests and server responses
z Routing of client messages to servers
z Coordination of two-phase commit when transactions access
multiple servers.
Some commercial TP monitors: CICS from IBM, Pathway from Tandem,
Top End from NCR, and Encina from Transarc
Database System Concepts - 6th Edition 26.3 ©Silberschatz, Korth and Sudarshan
TP Monitor Architectures
Database System Concepts - 6th Edition 26.4 ©Silberschatz, Korth and Sudarshan
TP Monitor Architectures (Cont.)
Process per client model - instead of individual login session per
terminal, server process communicates with the terminal, handles
authentication, and executes actions.
z Memory requirements are high
z Multitasking- high CPU overhead for context switching between
processes
Single process model - all remote terminals connect to a single
server process.
z Used in client-server environments
z Server process is multi-threaded; low cost for thread switching
z No protection between applications
z Not suited for parallel or distributed databases
Database System Concepts - 6th Edition 26.5 ©Silberschatz, Korth and Sudarshan
TP Monitor Architectures (Cont.)
Many-server single-router model - multiple application server
processes access a common database; clients communicate with the
application through a single communication process that routes
requests.
z Independent server processes for multiple applications
z Multithread server process
z Run on parallel or distributed database
Many server many-router model - multiple processes communicate
with clients.
z Client communication processes interact with router processes
that route their requests to the appropriate server.
z Controller process starts up and supervises other processes.
Database System Concepts - 6th Edition 26.6 ©Silberschatz, Korth and Sudarshan
Detailed Structure of a TP Monitor
Database System Concepts - 6th Edition 26.7 ©Silberschatz, Korth and Sudarshan
Detailed Structure of a TP Monitor
Queue manager handles incoming messages
Some queue managers provide persistent or durable message
queueing contents of queue are safe even if systems fails.
Durable queueing of outgoing messages is important
z application server writes message to durable queue as part of a
transaction
z once the transaction commits, the TP monitor guarantees
message is eventually delivered, regardless of crashes.
z ACID properties are thus provided even for messages sent
outside the database
Many TP monitors provide locking, logging and recovery services,
to enable application servers to implement ACID properties by
themselves.
Database System Concepts - 6th Edition 26.8 ©Silberschatz, Korth and Sudarshan
Application Coordination Using
TP Monitors
A TP monitor treats each subsystem as a resource manager that
provides transactional access to some set of resources.
The interface between the TP monitor and the resource manager is
defined by a set of transaction primitives
The resource manager interface is defined by the X/Open Distributed
Transaction Processing standard.
TP monitor systems provide a transactional remote procedure call
(transactional RPC) interface to their service
z Transactional RPC provides calls to enclose a series of RPC calls
within a transaction.
z Updates performed by an RPC are carried out within the scope of the
transaction, and can be rolled back if there is any failure.
Database System Concepts - 6th Edition 26.9 ©Silberschatz, Korth and Sudarshan
Workflow Systems
Database System Concepts - 6th Edition 26.11 ©Silberschatz, Korth and Sudarshan
Examples of Workflows
Database System Concepts - 6th Edition 26.12 ©Silberschatz, Korth and Sudarshan
Loan Processing Workflow
Database System Concepts - 6th Edition 26.13 ©Silberschatz, Korth and Sudarshan
Transactional Workflows
Must address following issues to computerize a workflow.
z Specification of workflows - detailing the tasks that must be
carried out and defining the execution requirements.
z Execution of workflows - execute transactions specified in the
workflow while also providing traditional database safeguards
related to the correctness of computations, data integrity, and
durability.
z E.g.: Loan application should not get lost even if system fails.
Extend transaction concepts to the context of workflows.
State of a workflow - consists of the collection of states of its
constituent tasks, and the states (i.e., values) of all variables in the
execution plan.
Database System Concepts - 6th Edition 26.14 ©Silberschatz, Korth and Sudarshan
Workflow Specification
Static specification of task coordination:
z Tasks and dependencies among them are defined before the
execution of the workflow starts.
z Can establish preconditions for execution of each task: tasks are
executed only when their preconditions are satisfied.
z Defined preconditions through dependencies:
Execution states of other tasks.
“task ti cannot start until task tj has ended”
Output values of other tasks.
“task ti can start if task tj returns a value greater than 25”
External variables, that are modified by external events.
“task ti must be started within 24 hours of the completion of task tj”
Database System Concepts - 6th Edition 26.15 ©Silberschatz, Korth and Sudarshan
Workflow Specification (Cont.)
Database System Concepts - 6th Edition 26.16 ©Silberschatz, Korth and Sudarshan
Failure-Automicity Requirements
Usual ACID transactional requirements are too strong/
unimplementable for workflow applications.
However, workflows must satisfy some limited transactional
properties that guarantee a process is not left in an inconsistent
state.
Acceptable termination states - every execution of a workflow will
terminate in a state that satisfies the failure-atomicity requirements
defined by the designer.
z Committed - objectives of a workflow have been achieved.
z Aborted - valid termination state in which a workflow has failed to
achieve its objectives.
A workflow must reach an acceptable termination state even in the
presence of system failures.
Database System Concepts - 6th Edition 26.17 ©Silberschatz, Korth and Sudarshan
Execution of Workflows
Database System Concepts - 6th Edition 26.18 ©Silberschatz, Korth and Sudarshan
Workflow Management System Architectures
Database System Concepts - 6th Edition 26.19 ©Silberschatz, Korth and Sudarshan
Workflow Scheduler
Ideally scheduler should execute a workflow only after ensuring that it
will terminate in an acceptable state.
Consider a workflow consisting of two tasks S1 and S2. Let the failure-
atomicity requirement be that either both or neither of the
subtransactions should be committed.
z Suppose systems executing S1 and S2 do not provide prepared-
to-commit states and S1 or S2 do not have compensating
transactions.
z It is then possible to reach a state where one subtransaction is
committed and the other aborted. Both cannot then be brought to
the same state.
z Workflow specification is unsafe, and should be rejected.
Determination of safety by the scheduler is not possible in general,
and is usually left to the designer of the workflow.
Database System Concepts - 6th Edition 26.20 ©Silberschatz, Korth and Sudarshan
Recovery of a Workflow
Database System Concepts - 6th Edition 26.21 ©Silberschatz, Korth and Sudarshan
Recovery of a Workflow (Cont.)
Persistent messages: messages are stored in permanent message
queue and therefore not lost in case of failure.
z Described in detail in Chapter 19 (Distributed Databases)
Before an agent commits, it writes to the persistent message queue
whatever messages need to be sent out.
The persistent message system must make sure the messages get
delivered eventually if and only if the transaction commits.
The message system needs to resend a message when the site
recovers, if the message is not known to have reached its destination.
Messages must be logged in stable storage at the receiving end to
detect multiple receipts of a message.
Database System Concepts - 6th Edition 26.22 ©Silberschatz, Korth and Sudarshan
High Performance
Transaction Systems
Database System Concepts - 6th Edition 26.24 ©Silberschatz, Korth and Sudarshan
Main-Memory Database
Commercial 64-bit systems can support main memories of tens of
gigabytes.
Memory resident data allows faster processing of transactions.
Disk-related limitations:
z Logging is a bottleneck when transaction rate is high.
z Use group-commit to reduce number of output operations (Will
study two slides ahead.)
z If the update rate for modified buffer blocks is high, the disk
data-transfer rate could become a bottleneck.
z If the system crashes, all of main memory is lost.
Database System Concepts - 6th Edition 26.25 ©Silberschatz, Korth and Sudarshan
Main-Memory Database Optimizations
Database System Concepts - 6th Edition 26.26 ©Silberschatz, Korth and Sudarshan
Group Commit
Idea: Instead of performing output of log records to stable storage as
soon as a transaction is ready to commit, wait until
z log buffer block is full, or
z a transaction has been waiting sufficiently long after being ready to
commit
Results in fewer output operations per committed transaction, and
correspondingly a higher throughput.
However, commits are delayed until a sufficiently large group of
transactions are ready to commit, or a transaction has been waiting
long enough-leads to slightly increased response time.
Above delay acceptable in high-performance transaction systems
since log buffer blocks will fill up quickly.
Database System Concepts - 6th Edition 26.27 ©Silberschatz, Korth and Sudarshan
Real-Time Transaction Systems
Database System Concepts - 6th Edition 26.28 ©Silberschatz, Korth and Sudarshan
Long Duration Transactions
Database System Concepts - 6th Edition 26.29 ©Silberschatz, Korth and Sudarshan
Long-Duration Transactions
Database System Concepts - 6th Edition 26.30 ©Silberschatz, Korth and Sudarshan
Concurrency Control
Database System Concepts - 6th Edition 26.31 ©Silberschatz, Korth and Sudarshan
Concurrency Control (Cont.)
A non-conflict-serializable
schedule that preserves
the sum of A + B
Database System Concepts - 6th Edition 26.32 ©Silberschatz, Korth and Sudarshan
Nested and Multilevel Transactions
A nested or multilevel transaction T is represented by a set
T = {t1, t2, ..., tn} of subtransactions and a partial order P on T.
A subtransaction ti in T may abort without forcing T to abort.
Instead, T may either restart ti, or simply choose not to run ti.
If ti commits, this action does not make ti, permanent (unlike the
situation in Chapter 15). Instead, ti, commits to T, and may still abort
(or require compensation) if T aborts.
An execution of T must not violate the partial order P, i.e., if an edge ti
→ ti appears in the precedence graph, then ti → ti must not be in the
transitive closure of P.
Database System Concepts - 6th Edition 26.33 ©Silberschatz, Korth and Sudarshan
Nested and Multilevel Transactions (Cont.)
Database System Concepts - 6th Edition 26.34 ©Silberschatz, Korth and Sudarshan
Example of Nesting
Database System Concepts - 6th Edition 26.35 ©Silberschatz, Korth and Sudarshan
Compensating Transactions
Database System Concepts - 6th Edition 26.36 ©Silberschatz, Korth and Sudarshan
Implementation Issues
For long-duration transactions to survive system crashes, we must log
not only changes to the database, but also changes to internal system
data pertaining to these transactions.
Logging of updates is made more complex by physically large data items
(CAD design, document text); undesirable to store both old and new
values.
Two approaches to reducing the overhead of ensuring the recoverability
of large data items:
z Operation logging. Only the operation performed on the data item
and the data-item name are stored in the log.
z Logging and shadow paging. Use logging from small data items; use
shadow paging for large data items. Only modified pages need to be
stored in duplicate.
Database System Concepts - 6th Edition 26.37 ©Silberschatz, Korth and Sudarshan
Transaction Management in
Multidatabase Systems
Database System Concepts - 6th Edition 26.38 ©Silberschatz, Korth and Sudarshan
Transaction Management
Local transactions are executed by each local DBMS, outside of the
MDBS system control.
Global transactions are executed under multidatabase control.
Local autonomy - local DBMSs cannot communicate directly to
synchronize global transaction execution and the multidatabase has
no control over local transaction execution.
z local concurrency control scheme needed to ensure that DBMS’s
schedule is serializable
z in case of locking, DBMS must be able to guard against local
deadlocks.
z need additional mechanisms to ensure global serializability
Database System Concepts - 6th Edition 26.39 ©Silberschatz, Korth and Sudarshan
Two-Level Serializability
DBMS ensures local serializability among its local transactions,
including those that are part of a global transaction.
The multidatabase ensures serializability among global transactions
alone- ignoring the orderings induced by local transactions.
2LSR does not ensure global serializability, however, it can fulfill
requirements for strong correctness.
1. Preserve consistency as specified by a given set of constraints
2. Guarantee that the set of data items read by each transaction is
consistent
Global-read protocol: Global transactions can read, but not update,
local data items; local transactions do not have access to global data.
There are no consistency constraints between local and global data
items.
Database System Concepts - 6th Edition 26.40 ©Silberschatz, Korth and Sudarshan
Two-Level Serializability (Cont.)
Local-read protocol: Local transactions have read access to global
data; disallows all access to local data by global transactions.
A transaction has a value dependency if the value that it writes to a
data item at one site depends on a value that it read for a data item on
another site.
For strong correctness: No transaction may have a value dependency.
Global-read-write/local-read protocol: Local transactions have read
access to global data; global transactions may read and write all data;
No consistency constraints between local and global data items.
No transaction may have value dependency.
Database System Concepts - 6th Edition 26.41 ©Silberschatz, Korth and Sudarshan
Global Serializability
Even if no information is available concerning the structure of the
various concurrency control schemes, a very restrictive protocol that
ensures serializability is available.
Transaction-graph : a graph with vertices being global transaction
names and site names.
An undirected edge (Ti, Sk) exists if Ti is active at site Sk.
Global serializability is assured if transaction-graph contains no
undirected cycles.
Database System Concepts - 6th Edition 26.42 ©Silberschatz, Korth and Sudarshan
Ensuring Global Serializability
Each site Si has a special data item, called ticket
Every transaction Tj that runs at site Sk writes to the ticket at site Si
Ensures global transactions are serialized at each site, regardless of
local concurrency control method, so long as the method guarantees
local serializability
Global transaction manager decides serial ordering of global
transactions by controlling order in which tickets are accessed
However, above protocol results in low concurrency between global
transactions.
Database System Concepts - 6th Edition 26.43 ©Silberschatz, Korth and Sudarshan
End of Chapter 26
Database System Concepts - 6th Edition 26.45 ©Silberschatz, Korth and Sudarshan
Figure 26.02
Database System Concepts - 6th Edition 26.46 ©Silberschatz, Korth and Sudarshan
Figure 26.03
Database System Concepts - 6th Edition 26.47 ©Silberschatz, Korth and Sudarshan
Figure 26.04
Database System Concepts - 6th Edition 26.48 ©Silberschatz, Korth and Sudarshan
Figure 26.05
Database System Concepts - 6th Edition 26.49 ©Silberschatz, Korth and Sudarshan
Extra slides
Database System Concepts - 6th Edition 26.51 ©Silberschatz, Korth and Sudarshan
Example Schedule with Degree-Two Consistency
T3 T4
lock-S (Q)
read (Q)
unlock (Q) lock-X (Q)
read (Q)
write (Q)
lock-S (Q) unlock (Q)
read (Q)
unlock (Q)
Database System Concepts - 6th Edition 26.52 ©Silberschatz, Korth and Sudarshan
Cursor Stability
Form of degree-two consistency designed for programs written in
general-purpose, record-oriented languages (e.g., Pascal, C,
Cobol, PL/I, Fortran).
Rather than locking the entire relation, cursor stability ensures that
z The tuple that is currently being processed by the iteration is
locked in shared mode.
z Any modified tuples are locked in exclusive mode until the
transaction commits.
Used on heavily accessed relations as a means of increasing
concurrency and improving system performance.
Use is limited to specialized situations with simple consistency
constraints.
Database System Concepts - 6th Edition 26.53 ©Silberschatz, Korth and Sudarshan