commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject Re: [lang] UUID Generator - was RE: UUID Generator?
Date Wed, 24 Dec 2003 23:08:56 GMT

--- Phil Steitz <phil@steitz.com> wrote:
> 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].

Sorry, I haven't been keeping up with this entire thread.  Take my
comments as a +1 for the Strategy suggestion then :-).

David

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


Mime
View raw message