commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Reilly" <tim.rei...@consultant.com>
Subject RE: [id] UUID update
Date Tue, 02 Mar 2004 01:39:32 GMT
> 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 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?


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