Академический Документы
Профессиональный Документы
Культура Документы
25.1
Chapter 1: Introduction
Part 1: Relational databases
Chapter 3: SQL
25.2
covers advanced data types and new applications, including temporal data,
spatial and geographic data, multimedia data, and issues in the management
of mobile and personal databases.
deals with advanced transaction processing. We discuss transactionprocessing monitors, high-performance transaction systems, real-time
transaction systems, and transactional workflows.
25.3
25.8 Summary
25.4
25.5
TP Monitor Architectures
process
25.6
process
25.7
process
process
25.8
process
process
Client communication processes interact with router processes that route their
requests to the appropriate server
Tandem Pathway
25.9
25.10
ACID properties are thus provided even for messages sent outside the
database
25.11
The interface between the TP monitor and the resource manager is defined
by a set of transaction primitives
Updates performed by an RPC are carried out within the scope of the
transaction, and can be rolled back if there is any failure
25.12
X Open/XA :
TP Monitor Distributed DB
25.13
Transaction RPC
25.14
25.3 E-Commerce
25.4 Main Memory Databases
25.5 Real-Time Transaction Systems
25.15
Transactional Workflows
Workflows are activities that involve the coordinated execution of multiple tasks
25.16
In the past, workflows were handled by creating and forwarding paper forms
Computerized workflows aim to automate many of the tasks
Disburse == Pay
Database System Concepts, 5th Ed.
25.17
Specification of workflows - detailing the tasks that must be carried out and
defining the execution requirements.
and the states (i.e. values) of all variables in the execution plan.
Database System Concepts, 5th Ed.
25.18
Workflow Specification
Static specification of task coordination:
Tasks and dependencies among them are defined before the execution of
the workflow starts.
Can establish preconditions for execution of each task: tasks are executed
only when their preconditions are satisfied.
E.g. Electronic mail routing system in which the text to be schedule for a given
mail message depends on the destination address and on which intermediate
routers are functioning.
Database System Concepts, 5th Ed.
25.19
Failure-Automicity Requirements
of a Workflow
Usual ACID transactional requirements are too strong / unimplementable for
workflow applications.
However, workflows must satisfy some limited transactional properties that
system failures.
25.20
Execution of Workflows
Execution of workflows may be controlled by a human coordinators or
25.21
workflows.
Fully distributed - has no scheduler, but the task agents coordinate their execution
by communicating with each other to satisfy task dependencies and other workflow
execution requirements.
25.22
Workflow Scheduler
Ideally scheduler should execute a workflow only after ensuring that it will
25.23
Workflow scheduler
25.24
Recovery of a Workflow
Ensure that if a failure occurs in any of the workflow-processing components, the
the time of failure, including the information about the execution states of each
task.
Handoff of tasks between agents should occur exactly once in spite of failure.
25.25
25.26
Recovery of a Workflow
25.27
Commercial Workflow
25.28
25.29
E-Commerce
E-commerce is the process of carrying out various activities related to
25.30
E-Catalogs
Product catalogs must provide searching and browsing facilities
Keyword search
Customization of catalog
25.31
E-Catalog
25.32
Marketplaces
Marketplaces help in negotiating the price of a product when there are multiple
Reverse auction
Auction
Exchange
Authenticate bidders
25.33
Types of Marketplace
Reverse auction system: single buyer, multiple sellers.
exchange matches buy-bids and sell-bids, deciding on price for the trade
e.g. average of buy-bids and sell-bids
25.34
Market Place
25.35
Order Settlement
Order settlement: payment for goods and delivery
Insecure means for electronic payment: send credit card number
25.36
make payment
Credit card company consolidates all payments from a buyer and collects
them together
*Impersonate = pretend
Database System Concepts, 5th Ed.
*fool = deceive
*consolidate = combine
25.37
Customer uses public key of certification agency to decrypt certificate and find
sellers public key
25.38
Digital Certificate
25.39
25.40
Digital Cash
Credit-card payment does not provide anonymity
But even with SET, buyer can be traced with help of credit card company
Digital cash systems provide anonymity similar to that provided by physical cash
E.g. DigiCash
25.41
Digital Cash
25.42
25.8 Summary
25.43
Parallel transactions may attempt to read or write the same data item,
resulting in data conflicts that reduce effective parallelism
25.44
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:
If the update rate for modified buffer blocks is high, the disk datatransfer rate could become a bottleneck.
25.45
25.46
No need to pin buffer pages in memory before data are accessed, since
25.47
a transaction has been waiting sufficiently long after being ready to commit
a higher throughput.
However, commits are delayed until a sufficiently large group of transactions are
25.48
Group Commit
25.49
25.50
25.51
Hard deadline Serious problems may occur if task is not completed within
deadline
Firm deadline - The task has zero value if it completed after the deadline.
Soft deadline - The task has diminishing value if it is completed after the
deadline.
The wide variance of execution times for read and write operations on disks
25.52
Real-Time DB
25.53
25.54
25.55
is required:
Long duration: Design edit sessions are very long
Exposure of uncommitted data: E.g., partial update to a design data
25.56
Graph-based Protocols
A transaction must hold a lock until there is no chance that the lock
will be needed again.
25.57
Validations Protocols
25.58
Concurrency Control
in Long Duration Transactions
Correctness without serializability:
25.59
a set T = {t1, t2, ..., tn} of subtransactions and a partial order P on T (i.e., t1 t2)
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 Ch 15).
25.60
25.61
T2
Get Lock-X(A)
T1,1 read(A)
Release Lock-X(A)
A := A-50
write(A)
T1,2 read(B)
Get Lock-X(B)
read(B)
B := B-10 T2,1
write(B)
Release Lock-X(A)
Get Lock-X(B)
B := B+50
write(B)
read(A)
A := A+10 T2,2
write(A)
Release Lock-X(A)
Get Lock-X(A)
Release Lock-X(A)
Pros:
Cons:
Database System Concepts, 5th Ed.
25.62
T1
T2
Get Lock-X(A)
T1,1 read(A)
A := A-50
write(A)
Implicitly Get Lock-X(B)
Get Lock-X(B)
read(B)
B := B-10 T2,1
write(B)
T1,2 read(B)
B := B+50
write(B)
read(A)
A := A+10 T2,2
write(A)
Pros:
Cons:
Database System Concepts, 5th Ed.
25.63
decrement operations:
T1 consists of
decrement operations:
T2 consists of
25.64
Compensating Transactions
in Long-Duration Transactions
Compensating transactions deal with the problem of cascading rollbacks
subtransactions
25.65
Implementation Issues of
Long Duration Transactions
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
Operation logging: Only the operation performed on the data item and the dataitem name are stored in the log.
Use logging from small data items and shadow paging for large data items.
25.66
You can either merge changes to the table with the parent, or discard these
changes.
Their original status and all subsequent changes to them are tracked using
versioned rows in tempdb database.
Benefit the ability to run multiple, parallel queries if long running transactions
interfere with the need for concurrent read access to frequently updated data
Drawback additional storage overhead, cost to maintain multiple version
25.67
25.8 Summary
25.68
Transaction Management
in Multidatabase Systems (contd)
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.
25.69
Transaction Management
in Multidatabase Systems Example
Global Transactions
Ti
Tj
GTM
LTM
Local Transactions
Local CC Protocol C1
Local Serializability
ti1
A type
DBMS
tj1
Global CC Protocol?
Global Serializability
LTM
ti2
tj2
Local Transactions
B type
DBMS
Local CC Protocol C2
Local Serializability
25.70
Commit Protocols
in Multidatabase Systems
In homogeneous distributed database, global atomicity is achieved if every
assumption of autonomy
But local DBMS may not use 2PC during the processing a global transactions
Some compromised approaches are available (but not covered here)
25.71
Concurrency Control
in Multidatabase Systems
Transaction management is complicated in multidatabase systems because of
Each local site uses a strict 2PL (locks are released at the end)
Locks set as a result of a global transaction are released only when that
transaction reaches the end
But
Due to autonomy requirements, sites cannot cooperate and execute a common
Mutidatabase CC Protocols:
25.72
Local data: data items belong to and are under the control of a particular site
Global data: data items are under the control of the multidatabase system
25.73
Local Transactions
d
Local data
Site 1
Site 2
Global data
Site n
Local and global constraints preserved
2SLR divides data items into local and global data items
25.74
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.
Local-read protocol ensures strong correctness if all these conditions hold
Local transactions have read access to global data
Disallows all access to local data by global transactions
No transaction may have a value dependency
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.
Global-read-write/local-read protocol ensures strong correctness if all these
conditions hold
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, 5th Ed.
25.75
Global-Read Protocol
Global Transactions
Local Transactions
d
Local data
Site 1
Global data
Site 2
Site n
25.76
Local-Read Protocol
Global Transactions
Local Transactions
d
Local data
Site 1
Global data
Site 2
Site n
25.77
Global-Read-Write/local-read Protocol
Global Transactions
Local Transactions
d
Local data
Site 1
Global data
Site 2
Site n
25.78
Global Serializability
in Multidatabase System
Early nave way of achieving global serializability: Read-only global transactions
Even if no information is available concerning the structure of the various
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.
Protocol for Global Serializability
Each site Si has a special data item, called ticket
25.79
S1
GT1
GT2
GT3
GT1
S2
GT3
GT2
25.80
Global Transactions T1
ticket
Site1
t1
Server 1 :
T3
ticket
a
r1(a)
Server 2 :
Local Transactions
b c
Site2
t2
w2(a)
r3(b)
w1(b)
Server 1 :
r1(t1)w1(t1++)r1(a)c1 r2(t1)w2(t1++)w2(a)c2
Server 2 :
Each transaction is supposed to have a time stamp by reading the ticket in the site
where the transaction poses its first read or write.
The global transaction manager controls ticket access with the same serializability
order in all sites.
Database System Concepts, 5th Ed.
25.81
25.82
They exist not just in computer applications, but also in almost all organizational
activities.
With the growth of networks, and the existence of multiple autonomous database
systems, workflows provide a convenient way of carrying out tasks that involve
multiple systems.
Although the usual ACID transactional requirements are too strong to implement for
They have since evolved, and today they provide the infrastructure for building
and administering complex transaction-processing systems that have a large
number of clients and multiple servers.
They provide services such as durable queueing of client requests and server
responses, routing of client messages to servers, persistent messaging, load
balancing, and coordination of two-phase commit when transactions access
multiple servers.
25.83
throughput.
In such systems, logging is a bottleneck.
Under the group-commit concept, the number of outputs to stable storage
can be reduced, thus releasing this bottleneck.
The efficient management of long-duration interactive transactions is more
25.84
The wide variance of execution times for read and write operations
complicates the transaction management problem for time-constrained
systems.
The local database systems may employ different logical models and datadefinition and data-manipulation languages, and may differ in their
concurrency-control and transaction-management mechanisms.
25.85
25.86
databases.
A storage manager for main-memory databases is described in Jagadish et
al.[1994].
Transaction processing in real-time databases is discussed by Abbott and Garcia-
Haritsa et al. [1990], Hong et al. [1993], and Pang et al. [1995].
Ozsoyoglu and Snodgrass [1995] is a survey of research in real-time and temporal
databases.
25.87
Moss [1985], Lynch and Merritt [1986], Fekete et al. [1990b], Fekete et al. [1990a],
Korth and Speegle [1994], and Pu et al. [1988].
Theoretical aspects of multilevel transactions are presented in Lynch et al.[1988]
[1995].
A model for concurrency in nested transactions systems is presented in Beeri et al.
[1989].
Relaxation of serializability is discussed in Garcia-Molina [1983] and Sha et al
.[1988].
Recovery in nested transaction systems is discussed by Moss [1987], Haerder and
25.88
and Schek [1984], Haerder and Rothermel [1987], Weikum et al. [1990], and
Korth et al. [1990a].
Salem et al. [1994] presents an extension of 2PL for long-duration transactions
[1990], Beribart et al. [1991], Beribart et al. [1992], Soparkar et al. [1991],
Mehrotra et al. [1992b] and Mehrotra et al. [1992a].
The ticket scheme is presented in Georgakopoulos et al. [1994]. 2LSR is
Elmagarmid[1989].
Database System Concepts, 5th Ed.
25.89
25.90
End of Chapter
91
to improve performance.
Degree-two consistency avoids cascading aborts without necessarily
ensuring serializability.
25.92
T3
T4
lock-S (Q)
read (Q)
unlock (Q)
lock-X (Q)
read (Q)
write (Q)
unlock (Q)
lock-S (Q)
read (Q)
unlock (Q)
25.93
Cursor Stability
Form of degree-two consistency designed for programs written in
constraints.
25.94