commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [lang] UUID Generator - was RE: UUID Generator?
Date Wed, 24 Dec 2003 22:22:36 GMT
David Graham wrote:
> --- Gary Gregory <ggregory@seagullsw.com> wrote:
> 
>>So the question perhaps becomes: should we provide a 100% Java solution
>>that
>>is not the "best" solution or a hybrid solution on "named" platforms
>>that is
>>the *best* solution for that given platform? Personally (especially if
>>the
>>thread-based UuidClock proves to be unworkable in 'real' servers), I
>>would
>>rather go for one of the extremes: provide nada and point users to the
>>article or provide the best (eventhough hybrid) solution.
> 
> 
> Why not use a Strategy pattern for pluggable time implementations?  The
> default strategy would use the best 100% Java implementation possible. 
> Users could then decide to implement strategies using the Java 1.5 nano
> second support or a native solution.

I agree. This is what we have been talking about for use in [uid].

Phil

> 
> David
> 
> 
>>Gary 
>>
>>
>>>-----Original Message-----
>>>From: Tim Reilly [mailto:tim.reilly@consultant.com]
>>>Sent: Tuesday, December 23, 2003 22:50
>>>To: Jakarta Commons Developers List
>>>Subject: RE: [lang] UUID Generator - was RE: UUID Generator?
>>>
>>>Hi Phil,
>>>
>>>I'm away for several days. I agree on the "clean room" uuid - I
>>
>>actually
>>
>>>got
>>>something together last night. I'll have better connectivity after the
>>
>>1st
>>
>>>of the year, hope to share more then.
>>>
>>>-TR
>>>
>>>
>>>>-----Original Message-----
>>>>From: Phil Steitz [mailto:phil@steitz.com]
>>>>Sent: Monday, December 22, 2003 3:24 PM
>>>>To: Jakarta Commons Developers List
>>>>Subject: Re: [lang] UUID Generator - was RE: UUID Generator?
>>>>
>>>>
>>>>Tim Reilly wrote:
>>>>
>>>>Sorry for the response latency.  See interspersed.
>>>>
>>>>
>>>>>I guess the short answer is.. if Tyrex was thought to be a good
>>>>
>>>starting
>>>
>>>>>point, this is how Tyrex does it.
>>>>>http://tyrex.sourceforge.net/api/tyrex/services/Clock.html
>>>>
>>>>(Same for OpenJMS
>>>>
>>http://openjms.sourceforge.net/xref/org/exolab/jms/util/Clock.html)
>>
>>>>>More on the clock issue:
>>>>>System.currentTimeMillis has some resolution issues in
>>>>
>>>>different jvm's and
>>>>
>>>>>OS's. That's the rationale behind this clock.
>>>>>>From JavaWorld article;
>>>>>http://www.javaworld.com/javaworld/javaqa/2003-01/01-qa-0110-
>>>>
>>>timing.html
>>>
>>>>>"Java developers on Linux enjoy 1-millisecond (ms) resolution,
>>>>
>>>>while Windows
>>>>
>>>>>98 users suffer with 50-ms resolution. In most cases, the
>>>>
>>>>actual resolution
>>>>
>>>>>has nothing to do with the fact that System.currenTimeMillis()'s
>>>>
>>>return
>>>
>>>>>value is current time in milliseconds." Also a MAC vm bug:
>>>>>http://developer.apple.com/qa/java/java20.html
>>>>
>>>>Thanks.  I see the rationale now.
>>>>
>>>>>I agree within containers that forbid thread creation shouldn't
>>>>
>>>>be counted
>>>>
>>>>>out.
>>>>>What if we had something like this:
>>>>>
>>>>>Uuid       -    Class representing a UUID. The recent post
>>>>
>>>>about kennewick
>>>>
>>>>>                is a good start for this class I think. Thanks
>>>>
>>Jorg.
>>
>>>>>UuidGen    -    Generates UUIDs, one can ask for a version 1,
>>>>
>>>>2, 3, or 4.
>>>>
>>>>>                Additionally, the default "clock" can be the
>>>>>System.currentTimeMillis,
>>>>>                but a setClock method provided. If
>>>>
>>currentTimeMillis
>>
>>>>>                is used then the CLOCK_SEQUENCE should be reset
>>>>
>>>>each call
>>>>
>>>>>b/c essentially
>>>>>                one can assume the time didn't move forward as
>>>>
>>>>it should.
>>>>
>>>>>UuidClock -        Interface
>>>>>UuidThreadClock -  Gives the artifical time based on thread clock
>>>>>UuidSystemClock -  Gives the artifical time based on system clock
>>>>>UuidFactory -      Attempts to create the best Uuid for the
>>>>
>>system.
>>
>>>>Looks promising.  An additional hurdle will obviously be the MAC
>>>
>>>address.
>>>
>>>>  In terms of the Uuid class, I took a quick look at the kennewick
>>>
>>stuff
>>
>>>>and I agree that it looks reasonable.  If we want to bring this in,
>>>>however, we will need to get a software grant and go through the
>>>
>>apache
>>
>>>>incubator. Given that there is not really that much there, it might
>>>
>>be
>>
>>>>just as well to clean room it here in the jakarta commons sandbox.
>>>>
>>>>Phil
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Phil Steitz [mailto:phil@steitz.com]
>>>>>>Sent: Wednesday, December 17, 2003 9:14 AM
>>>>>>To: Jakarta Commons Developers List
>>>>>>Subject: Re: [lang] UUID Generator - was RE: UUID Generator?
>>>>>>
>>>>>>
>>>>>>Phil Steitz wrote:
>>>>>>
>>>>>>
>>>>>>>Tim Reilly wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Phil, Tim, et al,
>>>>>>>>
>>>>>>>>I just added the thread lifecycle handling to the *draft*
>>>>>>>>UuidClock.java I'd
>>>>>>>>started
>>>>>>>>For the timestamp of a version 1 uuid.
>>>>>>>>
>>>>>>>>I'll share it here.
>>>>>>>>I realize it needs more work. I haven't tested it yet, but
I
>>>>>>>
>>wanted
>>
>>>to
>>>
>>>>>>>>get
>>>>>>>>some feedback before I do more.
>>>>>>>>
>>>>>>>>I'm not a committer on anything... would it be better to open
>>>>>>>
>>>>>>a bugzilla
>>>>>>
>>>>>>
>>>>>>>>enhancement and add files like this that way?
>>>>>>>
>>>>>>>
>>>>>>>Yes, it would be best to attach files to a Bugzilla ticket. I
>>>>>>
>>will
>>
>>>have
>>>
>>>>>>>a look this evening.  Is this meant to be used with the axis
>>>>>>
>>impl?
>>
>>>>>>
>>>>>>Tim,
>>>>>>
>>>>>>Can you provide a little more context on why we need this class
>>>>>
>>and
>>
>>>how
>>>
>>>>>>the overall solution will be structured?  I am a little concerned
>>>>>
>>>about
>>>
>>>>>>the need to spawn a thread for the timer, since this should be
>>>>>
>>usable
>>
>>>in
>>>
>>>>>>container-managed environments.
>>>>>>
>>>>>>Phil
>>>>>>
>>>>>
> === message truncated ===
> 
> 
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 




---------------------------------------------------------------------
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