Aren't GUIDs for this purpose?
http://en.wikipedia.org/wiki/Globally_Unique_Identifier ----- Original Message ----- From: "Fernando Padilla" <[EMAIL PROTECTED]> To: tc-dev@lists.terracotta.org Sent: Friday, August 29, 2008 3:11:14 AM GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: [tc-dev] [JIRA] Created: (CDV-875) duplicate sessions IDs are possible in TC sessions Here is a nice optimization. If the clientId is globally unique, you can easily have an in memory, vm local sequence, no need to go interacting with DSO datastructures and locks across a whole cluster. public class IdGenerator { private static long idCounter; private static String cliendIt; // initialized somehow public static synchronized newId() { idCounter = (idCounter+1) % Long.MAX_VALUE - 10; return clientId + "." + webappContext + "." + idCounter; } } I added the webappContext, because I'm used to having webapp specific class loaders, so the idCounter would be static only within a webapp. But if you have this class live outside at a top level classloader, then you need for a webappContext.. Tim Eck wrote: > Using the clientID would provide more "uniqueness" for sure (and is a good > idea, thank you) -- but with the current implementation it wouldn't be > enough. Within the same VM it would still be possible (in theory) to get a > collision. Using a TC transaction directly on the hashtable that stores > session seems like a fail safe way to detect collisions. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Fernando Padilla > Sent: Thursday, August 28, 2008 4:55 PM > To: tc-dev@lists.terracotta.org > Subject: Re: [tc-dev] [JIRA] Created: (CDV-875) duplicate sessions IDs are > possible in TC sessions > > can't you just concatenate the clientId? which is unique for the life of > the TC server? weird that the bug comment didn't mention that. > > > Terracotta JIRA (on behalf of Tim Eck) wrote: >> duplicate sessions IDs are possible in TC sessions >> -------------------------------------------------- >> >> Key: CDV-875 >> URL: https://jira.terracotta.org/jira//browse/CDV-875 >> Project: Community Development >> Issue Type: Bug >> Components: Sessions >> Affects Versions: 2.6.4 >> Reporter: Tim Eck >> Assignee: Issue Review Board >> >> >> The ID generator for TC sessions does not guarantee that a unique > session ID will be created for new sessions. DefaultIDGenerator uses a > SecureRandom and a local only counter, but that only makes the chances for > a collision very small, it does not ensure there not be a collision. The > ID generator will need to cooperate with the data store to ensure that key > does not exist before allowing to be issued to a request for a new session >> The problem gets worse when multiple contexts are clustered that all > have the same context path (but differing vhosts) (see CDV-206) since the > root for the session data store will be come to common to all of those > contexts. > _______________________________________________ > tc-dev mailing list > tc-dev@lists.terracotta.org > http://lists.terracotta.org/mailman/listinfo/tc-dev > _______________________________________________ > tc-dev mailing list > tc-dev@lists.terracotta.org > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
