commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: Gump & VM
Date Thu, 15 Dec 2005 09:41:56 GMT
Hi Martin,

> Jörg Schaible wrote:
>> And I doubt that it will help if the OS (or an appropriate
>> daemon task) is manipulating the system clock. The problem is
>> not too *less* resolution, it is too *much* - at least with
>> daemons adjusting system time smoothly. Descreasing the
>> resolution means, that the code might not be affected if such
>> a daemon shifts the system time by some millis into the past.

Martin van den Bemt wrote on Thursday, December 15, 2005 10:15 AM:

> Does a Thread.sleep(1) or something similar maybe help ?

Well, no, the id generator should produce as many ids as possible. The only requirement for
this one is, that you can recreate the time from the generated id and that the ids are generated
in a natural order. This is currently resolved by an internal counter that is resetted everytime
the current millis have changed. Decreasing the timer resolution to e.g. seconds means, that
this internal counter can get quite big or may even overflow and that the creation time is
not that accurate to recalculate. The current implementation works quite optimal for a non-time-shifting
environment. But if time shifts into the past happen, the natural order requirement is violated
(and detected by the unit tests) ... must think over it some more time ...

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message