RE: [stellation-res] Timing: The Solution

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Dave Shields
> >Sent: September 15, 2002 4:20 PM
> >To: stellation-res@xxxxxxxxxxxxxxx
> >Subject: Re: [stellation-res] Timing: The Solution
> >
> >
> >On Sun, Sep 15, 2002 at 11:10:50AM -0400, Jonathan Gossage wrote:
> >>
> >>
> >> There is a method that will deal with this scenario as well as
> >the previous
> >> one. If you force all files written to the workspace to have
> >timestamps 2
> >> seconds earlier than the current time then I think you will avoid the
> >> scenarios presented above.
> >
> >I am wary of forcing the timestamps to be wrong. Also, why just
> >two seconds?

The first round-down covers the fact that Unix systems always round down to
the lower bound.
The second second ensures that the checkin time and time stamp will always
be be less than any update that takes place during the checkin second but
after the actual checkin will always have a different time stamp.

I agree with you that this is ugly but it will cover those scenarios.
> >>
> >> However there is another scenario that is a real killer.
> >Consider a PC with
> >> a system clock that drifts forward in time one second per
> >hour. Consider
> >> also that this system updates its time each hour from a time
> >server. The
> >> result will be that once an hour approximately the local clock
> >will be set
> >> back by one second. This gap presents an opportunity for an update
> >> immediately following a checkin to get a back-dated time stamp that can
> >> cause the update to be missed.
> >>
> >> I have only presented two scenarios here, but I believe
> >thatthere are other
> >> possible ones. While the window of opportunity for failure is
> >quite small,
> >> it is real and if we want to deliver a robust product I do not
> >think that we
> >> should rely on a mechanism which is out of our control and
> >which can lead to
> >> missed checkins
> >>
> >I agree there is problem, but it's hard to see how we can
> >anticipate all scenarios.
> >
The problem really is that timestamp recording within a given second is not
deterministic and can be affected by many factors. If you read some of the
Team related posts on Eclipse you an see situations that seem to be rooted
in this problem. The problem is that while, overall, the number of actual
occurences will be very low, in particular scenarios such as the time server
one I presented the probability of an error in that particular environment
becomes much higher. I personally think that if you are to use timestamps as
a discriminant, youwill have to accept the certainity of some number of
errors which are likely to be very low in most scenarios but which can
become unacceptablly high in special cases. The issue than becomes one of
engineering trade-offs. Do we accept the certainty of a very small number of
errors in the vast majority of cases as the prce for a significantly more
efficient change detection scheme. Personally for a product like Stellation
where the integrity of source code is so important I would prefer the
conservative solution

> >dave
> >
> >PS: I have filed bug report to IBM's Java center re returning
> >bogus values from
> >java.io.File.lastModified(), after checking that the latest
> >version had the
> >same bug I found in an earlier version.
Even if this is fixed you will still have the other exposures I have
discussed.

Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx