"genman" wrote : Why are 4 and 5 even good ideas, let alone "requirements"? Yeah, sorry, just missed typing the "restriction" part. anonymous wrote : | As a user, I would want to specify where the static variable is stored and how and if it is replicated. The "registerClass" would essentially link a class to the cache. A class would have to belong to a single cache. Le'ts say we change your api naming first to "registerStaticVariableClass" to be more verbose. An additional api like that (and possibly unregisterStaticVariableClass) is certainly ok but like I mentioned it adds additional APIs to PojoCache, of which I'd like to avoid if possible, especially this won't be used often. Furthermore, there are 2 pitfalls: 1. There are some dependency on the static variable lifecycle. Consider this: | POJO.someStaticVar = 20; // setting but no replication yet. | cache = PojoCacheFactory.createCache(...); | cache.registerStaticVariableClass(Pojo.class); | // Still no POJO.someStaticVar replication yet unless we do | // POJO.someStaticVar = 30; to trigger replication. | // But now we failover to the other node and do | int val = POJO.someStaticVar; // this is not 20! | Of course this probably doesn't happen often but there is the possibility. 2. You will need to invoke this API in every cache instance in the clustering group (even the others are merely acting as passive backup) in order for it be funtion properly. E.g., cache1 and cache2 will need individually: | cache = PojoCacheFactory.createCache(...); | cache.registerStaticVariableClass(Pojo.class); | Otherwise, when you failover, the remote cache will have no knowledge of interceptiong the anonymous wrote : | 1. User needs to be able to specify which PojoCache they are replicating their object with. This is becaues it's a common use case to have multiple PojoCache instances per JVM. There are 2 difference cases for multiple PojoCache instances inside same vm: 1. Different clustering groups, e.g., one cache instance for http and another one for ejb, and furthermore the all use the same POJO static variable. a) They don't share the same POJO.statVar field and expect it to be replicated to a specific cache instance. In this case, only a specific cache instance is needed to replicate the static variable. Yes, we should support this fashion of usage. b) Both cache instances access the same POJO.someStaticVar and still expect only replicating the staticVar to a specific PojoCache instance, e.g., http one (but not the ejb one). This does not follow the regular Java semantics and IMO, I can't think of a use case for that now. 2. Same clustering groups, e.g., 1 VM has cache1 and cache2 but same jgroups channel. This is happening a lot in testing but is there other real life usage? anonymous wrote : | 2. User needs to be able to control (turn on/off) replication of the static fields. It needs to be off by default. This is because they might want to use this object in a situation where they aren't using JBossCache, e.g. on a simple client without JBoss Cache. | You are asking for fine-grained, runtime control to decide when to replicate and not. But I am thinking more of global wide cache control via POJO field annotation, @Replicatable. That is, if cache is declared properly and POJO is declared as well, then some static field replication will happen. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985196#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...