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
