Database Reference
In-Depth Information
SQL statements of this program
P(i)
which are executed during this transaction
ID
T
) and the subset of updated relations of the current consistent database instance
in data memory (obtained by
Out
DB
(st
(k))
in the current machine state
st
(k)
)are
saved.
Consequently, the execution of these
RA
arrows obtained after the variable bind-
ings use these “locally” updated relations by respecting X-locks on their tuples,
while the rest of relations are taken in
Out
DB
(st
(k))
.
Hence, the Buffer Manager manages the
n
≥
1 “local” partitions of the data
memory, one for each concurrent transaction, plus the last version of (committed)
instance-database in
Out
DB
(st
(k))
. In this way, each independent transaction (initi-
ated by different time-shared source programs
P(i),i
=
1
,
2
,
3
,...
) saves its “local
changes” (still non-committed, thus
possibly inconsistent
) independently from other
transactions.
Each transaction ends with COMMIT or ROLLBACK statements, while the new
transactions begin with CALL
n
,
n
3 statements by receiving a list
(n,
0
, ID
T
,L)
from
M
UC
when there is still no partition for this
ID
T
, as follows:
•
≥
When a list
(n,
0
, ID
T
,L)
is received from
M
UC
:
1. If there is still no partition for this
ID
T
, then the Buffer Manager creates a new
partition for this new transaction
ID
T
, by binding variables for the Application
Plan
P
n
and saving the obtained
RA
arrow in an internal list of this partition.
Then this
RA
arrow is executed by using (and by respecting X-locks) the
relations of the current consistent database in
Out
DB
(st
(k))
. However, the
resulting relation is saved only in this local partition, without changing the
database in
Out
DB
(st
(k))
.
2. Otherwise, if there is a partition for this transaction, then a new
RA
arrow
is generated by variable binding and it is saved at the end of the existing list
of the previously generated
RA
arrows during this transaction. Then this
RA
arrow is executed by using (and by respecting X-locks) the locally updated
relations in this partition and the rest of relations from
Out
DB
(st
(k))
.The
generated new relation will be saved locally in this partition, or will substitute
the previous version of the same relation in this partition. Again, the data the
database in
Out
DB
(st
(k))
is not changed.
•
When a transaction
ID
T
=
N
a
ends with a COMMIT, in the current machine state
st
(k)
, then all “locally” saved relations of this transaction are deleted and the or-
dered saved list of
RA
arrows are executed
again
but the resulting relations of
the execution of each single
RA
arrow are directly saved in the current database
instance in
Out
DB
(st
(k))
. These executions guarantee that all updates during
this transaction
ID
T
are done on the last consistent version of the database (be-
cause during this transaction
ID
T
=
N
a
this instance-database may be changed
by the COMMIT of some different transaction
N
b
of another concurrent program
P(j)
). At the end, all saved
RA
arrows of this transaction are deleted and this
partition in data memory is eliminated.
•
When a transaction
ID
T
=
N
a
ends with a ROLLBACK then simply the partition
of this transaction is eliminated (with all updated relations and
RA
arrows in it)
and hence the current consistent database in
Out
DB
(st
(k))
remains unchanged.
