[jboss-jira] [JBoss JIRA] Resolved: (JBAS-3720) Change structure of ClusteredSSO data in tree cache to avoid lock issues

[Hany Mesha (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-3720?page=all ]

Hany Mesha resolved JBAS-3720.
------------------------------

    Resolution: Done
      Assignee: Brian Stansberry  (was: Hany Mesha)

changed the fqn for sessions map in TreeCacheSSOClusterManager 

The change is done in the following method:

private Fqn getSessionsFqn(String ssoid)
   {
      Object[] objs = new Object[]{SSO, ssoid, localAddress, SESSIONS};
      return new Fqn(objs);
   }

Note that the original fqn didn't have localAddress as part of the node structure in the tree cache. With this change the sessions associated with the SSO ID will be identified by the server that this SSO cluster manager running on.

Brian, Please confirm the change and close the issue. Thanks!

Due to the fact that the test suite is broken, I didn't have chance to test this change. However, there's no special test cases that need to be written to verify the change. So once the test suite is repaired, the verification would be running the SSO test cases to success.



> Change structure of ClusteredSSO data in tree cache to avoid lock issues
> ------------------------------------------------------------------------
>
>                 Key: JBAS-3720
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3720
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.CR1
>
>
> For each SSO entry, their should be child node per server where the SSO has been used.  This is different from the current where all the session data for an SSO is in one node. The data map in each child node would hold the session ids of the sessions active on that server.
> This kind of structure avoids most lock contention between different servers.
> Can't do this in 4.0.x as it prevents interoperation with earlier releases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira