commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [id] Fooled by SessionIdGenerator
Date Sat, 13 Nov 2004 14:50:39 GMT
Jörg Schaible wrote:
> Phil Steitz wrote:
>>You are correct that the SessionIdGenerator does not wrap a singleton
>>generator, but expects to "be" a singleton.  The IdentifierUtils class
>>provides methods for statically accessing this and other generators.  In
>>the test below, if you used IdentifierUtils.nextStringSessionIdentifier()
>>instead of creating a new generator each time, you would be very unlikely
>>to see duplicates.
> But my plugin would grow significantly in size, since all thouse
> dependencies necessary for VersionOneGenerator ... well, it's the discovery
> only. IIRC that there were some more last time I checked ...

Good point. Need to look at this.
>>Alternatively, of course, you could create your own 
>>singleton and reuse it.

Probably better if you do not want to bring in the dependencies with the 
current setup.

   I will update the javadoc and userguide to make
>>it clearer what the expected usage is.  We discussed this before (could be
>>when the code was still in [lang]?) and concluded that it was best to
>>leave the flexibility to create multiple instances in and provide the
>>static methods in the utils class.
>>You are also correct in pointing out the the VersionFourGenerator works
>>differently.  In some sense, the UUID generators have a "global contract"
>>-- i.e., it does not make sense to have two distinct singleton instances
>>running in one JVM.  IIRC, this is why it uses static Random /
>>SecureRandom instances.
> Isn't it that, what SessionIdGenerator also proposes? Generating unique ids
> withing one JVM? So how is it really different (concerning one JVM)? By
> turning the Random into a static you'll have as much SessionIdGenerators as
> you like without having to fear an id clash.

The javadoc is defintely misleading here. What it says was true in the 
[lang] implementation but is not true now. I am having a hard time coming 
up with use cases or design reasons that the generator should not be 
static, so unless someone else objects, I am going to go ahead and make 
the change that you suggested. Thanks again for pointing this out.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message