Databases Reference
In-Depth Information
then-current knowledge of the contents of the database, specifi-
cally of what the database then asserted about what P861 was
like in May and June of 2012. If that description is allowed to
change before the later assertion became current, then all bets
are off.
Another way to think about the locking associated with
deferred transactions and deferred assertions is that it
serializes
those transactions. If a process about to update a row in a data-
base does not first lock that row from other updates, then
another update process could read the row before the first pro-
cess is complete. Then, whichever process physically updates
that row on the database first, its changes will be lost,
overwritten by the changes made by the process which updates
the database last. This could happen with deferred assertions if
they were not serialized.
The mechanics of deferred assertion locking are simple. Every
temporal transaction has an assertion begin date, either the
default date of Now() or an explicitly supplied future date. Tem-
poral updates and temporal deletes begin their work by
withdrawing the one or more versions which represent an object
in any clock ticks included in the transaction's effective
timespan. The versions they withdraw are those versions located
in the most recent period of assertion time. That may be current
assertion time, and usually is. But when a deferred transaction
has been applied to versions in current assertion time, it closes
their assertion periods with the same date that begins the asser-
tion period of the deferred assertion it creates, just as the
deferred update we are discussing closed P861(r6) and sup-
erceded it with P861(r8). And it creates a version that exists in
future assertion time. Deferred transactions may then be applied
to that deferred assertion, and we will explain how to do that in
the next section.
Note what is
not
locked. The episode itself is not locked. Out
of the entire currently asserted effective time period from
November 2011 to 12/31/9999, for P861, only two months have
been locked. Inserts, updates and deletes can continue to take
place against any of the other clock ticks in the episode occupied
by P861—or, for that matter, against any clock ticks not occupied
by P861.
We have now completed the deferred transaction. As
directed by the transaction, the AVF has created a version of
P861, for the effective time months of May and June 2012,
that will not be asserted until January 2090. If nothing
happens between now and January 2090, then at that time,
the database will stop asserting that P861 had a copay amount
