Databases Reference
In-Depth Information
ty
i
's profile. The template specifies the kind of objects that transactions of
type
ty
i
could read. Later on when a transaction
T
i
is executed, the template
for
type
(
T
i
) will be
materialized
to produce the read set of
T
i
using the input
arguments of
T
i
(Note that these input arguments are embedded in
T
i
's SQL
statements). This method is transparent to the DBMS kernel, however, in
some scenarios it can only obtain approximate read sets.
In [73], the DBMS is extended to provide support for read triggers. In con-
trast, commercial DBMSes only support insert/update triggers. This method
can obtain the exact read sets and it has reasonable run-time overhead, but
it requires a major extension to the kernel.
In [70], a more aggressive approach is taken to maintain the read-from
information. In this approach, Recovery Manager, the “core” of commercial
transaction management systems, is modified to log reads. In particular, when
the system commits a transaction, all the read information about the trans-
action will be consolidated into a single log record; then this special reads-
keeping log record will be forced onto the disk together with other writes-
keeping log records. This approach has minimal run-time overhead, but it
requires the largest amount of changes to the DBMS kernel.
Static Repair via History Rewriting
From the correctness point of view, both data-oriented methods and transaction-
oriented methods would result in a history that is
conflict equivalent
to the
serial
history composed of only the legitimate, unaffected transactions. (
C
(
H
1
)
is conflict equivalent to
C
(
H
2
) if they contain the same set of operations and
they order every pair of conflicting operations in the same way.) Nevertheless,
the history rewriting framework proposed in [74] shows that if we relax the
correctness requirement from conflict equivalence to
view equivalence
,wemay
even save the work of affected transactions.
In particular, by exploiting two new semantic relationships between trans-
actions, denoted
can-follow
and
can-precede
, respectively, the history rewrit-
ing framework can rewrite every “infected” history, which always starts with
a malicious transaction, to a ready-to-repair history in which every legiti-
mate, unaffected transaction precedes all the malicious transactions. Such a
rewritten history typically looks like the following. Here,
G
i
is a legitimate,
unaffected transaction and
AG
i
is an affected transaction. In addition,
F
i
is
called a
fix
. A fix for a transaction like
B
1
is a set of variables read by the
transaction given values as in the original position of the transaction before
the history is rewritten.
G
i
1
...AG
j
1
...G
in
...AG
jm
B
F
1
...B
F
l
...AG
F
kp
AG
F
k
1
k
1
1
kp
The study in [74] shows that (a) each rewritten history and the original
history will result in the same final database state, and (b) the work of all the
legitimate transactions preceding
B
F
1
1
in the rewritten history can be saved
by executing a specific compensating transaction for each of the transactions
