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 Fri, 12 Nov 2004 17:44:23 GMT
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.
 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
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.
Sorry the docs were not clear and thanks for pointing this out.

	-----Original Message----- 
	From: "Jörg Schaible" [] 
	Sent: Fri 11/12/2004 8:24 AM 
	To: Jakarta Commons Developers List 
	Subject: [id] Fooled by SessionIdGenerator

	Hi folks,
	in my current application (a kind of plugin - the plugin is just called from time to time)
I was fooled by the SessionIdGenerator. I chose this one instead of a UUID generator because
of a length limitation of my unique keys and since I had a lengthly discussion with Phil about
the reliable uniqueness of the keys. Now, the length limitation was introduced later in the
project and I just switched from a VersionFourGenerator to SessionIdGenerator. Unfortunately
we had to detect in the current test phase, that it happened sometimes, that obviously two
identifiers had the same value.
	I tracked it down to a unit test:
	    public final void testIdentityGenerator() {
	        final Set set = new HashSet();
	        for(int i = 0; i < 10000; ++i) {
	            final IdentifierGenerator idGenerator = new SessionIdGenerator();
	        assertEquals(10000, set.size());
	this works for the VersionFourGenerator without problem. Looking at the source everything
got clear: The SessionIdGenerator expects to be *himself* the singleton, while the VersionFourGenerator
uses a singleton internally. To make this work, a simple change is necessary: Make the internally
used Random object a static. Otherwise there's always a good chance, that two Random objects
get initialized in the same millisecond fraction.
	To unsubscribe, e-mail:
	For additional commands, e-mail:

View raw message