Bit of a post to myself to document some thoughts that I'm not going to deal with right away... The prescribed jboss-aop.xml for FIELD granularity session attribute POJOs includes introduction of a Subject mixin. This is problematic, as the standard jboss-aop.xml in the PojoCache dist does not include this mixin for @PojoCacheable. Getting rid of the need for this mixin would be nice. But... Usage of the mixin: When the pojo is bound to the session, the session registers itself as an Observer. So, when the pojo is modified, the session knows it is dirty. At the end of the web request, this triggers replication of the session metadata (update version, timestamp, etc.) Benefits: 1) Session timestamp is replicated, reducing chances that the session will be timed out on another node and flushed from that node's cache. Flushing a live FIELD session is bad, as future requests for the session won't replicate the whole set of cache nodes associated with the session. So, the server where the session was flushed will likely never again have the whole set of cache nodes. There are other safeguards to ensure the timestamp is replicated (e.g. a request that occurs after > 80% of the timeout interval has gone by automatically causes the metadata to replicate. But this isn't perfect. 2) Session version is replicated. This helps in cases where sticky session enforcement is spotty, and another server thinks it is the one hosting the session. The version replication tells it it is not, and that it's locally cached copy is out of data vs. the cluster. If the user fails back over to this server, if the session version hadn't been replicated, the user will see stale data. This is a bit of an edge case, as it requires multiple failovers. Limitations and other approaches: The use of the Subject mixin doesn't work in all cases, e.g. with Collections. So, for 4.2.0 I added TreeCacheListener event handling where modifcation of nodes underneath a session's root trigger marking the session as dirty. Thus for pojo updates affecting nodes under the session root, the session will know it is dirty, making the Subject mixin unneeded. Problem is pojos will not necessarily be stored under the session root. Shared objects may be stored elsewhere. In JBC 2.0, pojos will be stored in a special internal area. For such situations, using a TreeCacheListener and trying to determine from an event Fqn what session is affected will not work. If we require that the only scope for pojo sharing is within the session, then perhaps all pojos will be stored under the session root. This would imply that in 2.0 there would be an internal area for each session. This may be a viable solution. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020846#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...