[jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Scoping of FIELD granularity session pojos

Currently, pojos stored in a FIELD replication granularity web session are stored in a section of the cache scoped to the webapp, not to the session. I'm more and more inclined to change this to session scoping, and would appreciate any comments anyone may have. Allowing different sessions to share pojos has a fundamental drawback, plus it introduces a number of implementation hassles: Fundamental drawback is users running on different nodes can attempt to concurrently modify the pojo. This can lead to anomalous behavior or distributed deadlocks Implementation hassles: 1) Can't passivate pojos along with sessions. Making them sharable gives them an independent lifecycle, so they can't be stored in the cache in the subtree belonging to a particular session. So, evicting a session's subtree doesn't remove the pojos. Leads to the need for a very hacky and imprecise introduction of raw JBC node eviction concepts into jboss-web.xml to let users configure pojo eviction. 2) Data gravitation. Again, sharable pojos can't be stored under a session's subtree. So, gravitating that subtree following failover doesn't bring the associated pojos. That has to be managed separately, and requires telling PojoCache to always do a data gravitation check any time it doesn't find something in the cache. That's inefficient when new objects are inserted. Plus I haven't gotten it work properly yet now that PC no longer does it by default. ;) 3) Ownership with buddy replication. Related to data gravitation. If a pojo is shared and the sessions sharing it end up on different nodes, the shared pojo will start getting gravitated back and forth between between the nodes. This is contrary to the whole idea of buddy replication, which is that data is owned by own node and only moves to handle failover. Possible solutions: 1) Store pojos under the session that first passes them to setAttribute. Pros: solves above problems Cons: if webapp stores the same pojo under two different sessions, PC will support this. But if the first session is removed, the underlying pojo will be removed with it and if the second session tries to use it they will get an exception. 2) Make it configurable via a pojo-scope element in jboss-web.xml, valus are APPLICATION or SESSION, default is session. Basically, still support the existing behavior. Log a WARN if user specifies ATTRIBUTE with a buddy replication cache. Pros: give people who count on current behavior a way out. Cons: ignores the "fundamental problem" discussed above. Requires supporting the hacky JBC eviction configuration via jboss-web.xml stuff. Comments? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146547#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...