"ENHANCED ALGORITHMS FOR TIMER TRIGGER PROCESSING"
(UF CISE DEPARTMENT TECHNICAL REPORT TR-99-015)
CONCERNING ISSUES RELATED TO UPDATES THAT TAKE PLACE AT TIMER
Lloyd X. Noronha
Eric N. Hanson
University of Florida
9 Sep 1999
Every interesting update to a data source R is recorded in a set S. When the timer
expires, a new copy of the view CurrView is created from its old copy by getting the
newest update information for the keys recorded in S. A question now arises, on whether
everything is correctly handled during timer boundaries. In particular, what happens to
updates that take place during the time from when the timer expires until the processing
for that trigger ends, and if any permutation of events could introduce incorrect or
outdated data into the view, that does not get corrected later. The scope of this addendum
is to correctly explain the behavior of the algorithm at timer boundaries and answer these
One extra step needs to be added for all the algorithms presented in the thesis. At
timer expiration for a single table timer trigger, the following steps are performed:
1. Copy the contents of S into S' and empty the contents of S. This should be one
atomic operation with an update lock on the relation S.
2. Apply the relevant algorithm presented in the thesis to process the timer
trigger, but using S' instead of S.
In case of a multi-table trigger, copies of all S sets for each relation needs to be
made before proceeding with the algorithm.
Let's consider how updates in R at different times affect the functioning of the
algorithm. Consider figure 1, which is divided into different regions explained below.
The shaded region is where the timer trigger is processed. In the interval between tl and
t2 is when step 1 executes and between t2 and t3 is when step 2 executes. A tuple with a
key kl undergoes updates in different regions of the figure. Initially the tuple (kl, vO) is
present in the view CurrView, which represents the value of the tuple in R at the last
timer expiration. The tuple then undergoes updates to values vl, v2, v3 and v4 in the
various regions of the figure.
Step 1 executes Step 2 executes
1 2 3 4
(vl) (v2) (v3) (v4)
tl t2 t3
Region 1 represents the time between when the processing for the previous timer
expiration ends and the before the next one begins at tl. If the tuple was updated one or
more times before tl, then the key kl would be recorded in S. Let vl be the value of the
last such update in region 1. Now when the processing for the timer trigger begins at tl,
the algorithm should get tuple (kl, vl).
Region 2, from time tl to t2, is when step 1 of the above-mentioned procedure
executes. The tuple in R is updated to have value (kl, v2). However, since there is an
update lock on S while its contents get copied to S' the key value gets recorded in the
new S set only after the locks are released at time t2.
Region 3, from time t2 to t3, is when step 2 of the above-mentioned procedure
executes. The tuple in R is updated to have value (kl, v3). Step 2 reads the newly updated
information for this tuple from the relation R and uses it for processing the timer trigger
and refreshing the view. The value v2 or v3 will be read from R depending on whether
the update took place after the read or before.
Region 4, This region represents the time between when the processing for the
current timer expiration ends and before the next one begins.
Although it was intended for the timer trigger to use the value (kl,vl), it may get
the value (kl, v2) or (kl, v3) during processing. So, any updates made in the shaded
region of the figure may or may not be seen by the algorithm, depending on when the
update took place. This causes the enhanced processing to behave slightly differently
from the brute force approach, which always sees the correct value (kl, vl).
On the next expiration of the timer, the key kl will be present in S and the
algorithm will refresh CurrView with the value of that tuple at that time. So, there is no
way a particular sequence of updates at timer boundaries can cause any permanent
damage to the view.
It is also interesting to consider what happens in the algorithm when only one of
the four updates takes place. If only update vl takes place, then kl is recorded in S before
tl and the correct value (kl, vl) is used. For update v2, kl is not recorded in S and this
update will not be seen until the next timer expiration. The same applies for update v3.