commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adkins Kendall <Kendall.Adk...@HCAhealthcare.com>
Subject RE: [id] UUID update
Date Thu, 04 Mar 2004 04:19:44 GMT
Here is a UID Generator we are using.  Part of the UID contains the hash of
a final static object instance.  In this way, while a JVM is up you are
assured no other objects can occupy the same memory address.  We have had no
difficulty with it under heavy load across 4 servers each with three JVMs.



-----Original Message-----
From: Phil Steitz [mailto:phil@steitz.com]
Sent: Wednesday, March 03, 2004 9:56 PM
To: Jakarta Commons Developers List
Subject: Re: [id] UUID update


Tim Reilly wrote:
>>I will look at this stuff carefully this weekend, but one thing that
>>jumped out at me from your post above was that the "global lock" issue
>>might be avoidable by putting more into the node identifier, i.e., build
>>in a jvm identifier.  IIRC, this is essentially what tomcat when
>>generating session ids to avoid collisions across jvms on the same host.
>>Just something to think about.
>>
>>Phil
>>
> 
> 
> I'm back. I'm thinking about this suggestion... My original concern is
both
> with physical machines that run multiple jvm versions, as well as multiple
> instances of the same jvm (such as in an application server that is
> vertically clustered.)
> 
> I don't know of an identifier that I can get that uniquely identifies a
jvm
> instance, but there may be something (I'll dig around the tomcat code.)
> Coincidently, I do iterate the System properties and then create an MD5 of
> those concatenated with a random and a (new Object().hashCode()) to
generate
> an artificial node id in StateHelper (used in the InMemoryStateImpl). Keep
> in mind, that *ideally* the Node.id is always the MAC address(s) though.

I investigated the tomcat code and concluded that my suggestion above is 
no better/different really than what you are doing and has the 
disadvantage of making the node id nonstandard (bad). AFAIK, there is no 
magical way to generate a guaranteed unique jvm identifier.

> I think I submitted quite a bit to digest in the zip file. Something that
> may make things easier all around might be if I start on creating patches
> just for the VersionFour uuid generator (random uuid)? We can workout
> naming, package structure, and how best to tie in the factory and
> IdentifierUtils.
> Afterwards, we can look at the decisions about the more
complex/troublesome
> version 1 generator.
> If this sounds good to everyone I'll start a new thread around that?
> 
> 
I went ahead and committed the changes in the zip, with no changes other 
than updating the Apache license to 2.0. This is a good start. We need to 
get a better feel for stability / performance and some more eyeballs on 
this code, so I thought it best to get it into CVS now, even if we decide 
to refactor / repackage down the road. Thanks for the contribution.

Some minimial xdocs, or more complete package documentation describing the 
implementation choices made would be a good thing to add about now.  Most 
of this is in the code or mail archives, but it would be good to get it 
into the package docs or xdocs.

If you have not been following all of the commons-dev build stuff, you may 
have missed that you now need to co jakarta-commons-sandbox/sandbox-build 
to get the maven build to work.

Phil

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