[jboss-jira] [JBoss JIRA] Updated: (JBAS-4639) Optimized replication of ClusteredSession metadata
Brian Stansberry (JIRA)
jira-events at lists.jboss.org
Tue Jun 3 10:15:20 EDT 2008
[ http://jira.jboss.com/jira/browse/JBAS-4639?page=all ]
Brian Stansberry updated JBAS-4639:
-----------------------------------
Fix Version/s: JBossAS-5.0.0.CR1
(was: JBossAS-5.0.0.CR2)
Moving back to CR1 as the core of it is done and it should be in release notes. If not completely done by June 9 I'll create subtasks for missing bits and schedule them for CR2.
> Optimized replication of ClusteredSession metadata
> --------------------------------------------------
>
> Key: JBAS-4639
> URL: http://jira.jboss.com/jira/browse/JBAS-4639
> 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
>
>
> Stop storing clustered session metadata as a single key value pair in JBossCache. Instead, separate those attributes prone to frequent change (s/b just the access timestamp) from those that are largely fixed at session creation. Call cache.put() with the "fixed" ones only on the first request (or in the less likely event that something changes in them, e.g. timeout interval, in a later request.) Store the timestamp with every request; perhaps less often if the request didn't change anything else in the session, i.e. no more often than every 30 secs.
> With this we can get rid of hacky stuff like using Subject/Observer to track FIELD granularity pojo attribute changes. We just do that so we know whether to replicate session the metadata.
--
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
More information about the jboss-jira
mailing list