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 21:21:51 GMT

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

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


Mime
View raw message