> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
