commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject RE: [id] Fooled by SessionIdGenerator
Date Fri, 12 Nov 2004 22:17:15 GMT
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 ...

> Alternatively, of course, you could create your own 
> singleton and reuse it.  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.

> Sorry the docs were not clear and thanks for pointing this out.

Well, if you've been trapped once, you'll normally know the next time ;-)

- Jörg

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

View raw message