[jboss-jira] [JBoss JIRA] Updated: (JBAS-4067) Collection modifications do not trigger FieldBasedClusteredSession version update

[Brian Stansberry (JIRA)]

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

Brian Stansberry updated JBAS-4067:
-----------------------------------

    Summary: Collection modifications do not trigger FieldBasedClusteredSession version update  (was: Collection modifications do not trigger FieldBasedClusterdSession version update)

> Collection modifications do not trigger FieldBasedClusteredSession version update
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-4067
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4067
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering
>    Affects Versions: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.2.0.CR1
>
>
> FIELD granularity session replication relies on the AOP Subject/Observer pattern to detect changes in session attribute pojos and trigger a notification to the session object.  The notification marks the session dirty, which in turn causes a replication of an updated version int for the session.  Other nodes use the version int to detect if their locally cached session is out of sync with the distributed cache.
> Using Subject/Observer breaks down with collections.  The registration of the session as Observer happens as part of the setAttribute call.  But if an object is added to a collection following that call, it will not be observed.  Also, the collection itself is not normally aspectized.
> Test case for this is FieldBasedTestCase.testCollectionModification().
> Effect is not critical.  The changed session content *is* replicated.  The missing replication is the session version.  This would only be an issue if session stickiness were not working correctly, and:
> 1) Session starts out on cluster node A, with last request leaving it at version, say, 5.
> 2) Session fails over to cluster node B.  Modifications occur as described above, leaving session at version 6.
> 3) Session fails back over to cluster node A.  Manager on A thinks its locally cached session is OK, so it doesn't read the version from the cache.
> Fix is to use the CacheListener to note events in the cache and mark the session dirty.  Leave the Subject/Observer solution in place in case the same POJO is stored in multiple session (in which case the cache listener event would only notify a single session.)

-- 
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