[jboss-jira] [JBoss JIRA] Closed: (JBAS-4067) Collection modifications do not trigger FieldBasedClusteredSession 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.)