[jboss-dev-forums] [Design of JBossCache] - Re: static field replication in PojoCache

[ben.wang@jboss.com]

"bela at jboss.com" wrote : #1 Why do we need to annotate someStaticVar in the first place ? Since the class is tagged as  @PojoCacheable (that's a stupid name, let's change it to @Replicated or @Clustered !!), someStaticVar needs to be replicated as well !

First of all, let me address the PojoCacheable naming at the end.

I introduced that field annotation (@Replicatable) becuase I reckon there may be a case I don't want to replicate 1) any of the POJO static variables at all (this is happening most often); or 2) all of my static variables, e.g.,


  | org.jboss.cache.pojo.annotation.PojoCacheable
  | public class POJO
  | {
  |    @org.jboss.cache.pojo.annotation.Replicatble
  |    public static int someStaticVar;
  |    
  |    public static int anotherStaticVar; // this one won't get replicated.
  |   ...
  | }
  | 

So the annotation essentially allows user to replicate the static variable of her choice.

anonymous wrote : #2 Of course we need to support another static variable ! Ideally we adhere to the Java semantics

Sure, it will be supported. I meant in my originally post that we won't support a static variable of "aspectized" POJO type, e.g.,

  | org.jboss.cache.pojo.annotation.PojoCacheable
  | public class Foo
  | {
  | ...
  | }
  | 
  | org.jboss.cache.pojo.annotation.PojoCacheable
  | public class POJO
  | {
  |    @org.jboss.cache.pojo.annotation.Replicatble
  |    public static Foo someStaticVar; // we cant support that someStaticVar is of type Foo of which is PojoCacheable.
  |   ...
  | }
  | 

Reason? Well, static variable is usually initialized failry early in the program lifecycle. So support of another POJO type to be managed by the PojoCache can be troublesome. I imagine mostly the static type to be primitive. Or am I assuming too much?

anonymous wrote : #3 Sure. Implementation issue correct ?
  | 
  | #4 Or lazy, whatever. Implementation issue again

Yes, implementation issues.

anonymous wrote : #5 Why ? we can have N someStaticVars per *cluster*...

Now I don't get you. If someStaticVars is replicated, then there can only be a someStaticVar per *cluster* (sure, different VM will have their own instances). I was proposing to allow inside each VM, only one PojoCache instance is allowed to have static variable replication. Elias' discussion is also focused on this area as well.

Finally, on the naming of @PojoCacheable instead of @Clustered or @Replicated. I have thought about that before. I think @Clustered or @Clusterable is not appropriate becuase we are talking about state replication only (i.e., no client side load balancing).

As for @Replicated, it is possible. But the expectation will be different. E.g., a user should not expect that once the Pojo is annotated and instantiated, then thing will happen automatically. That is, we are not using the API-less model; we still need to have api to *attach* the POJO. So @Replicated tag is a bit overloaded, IMO.




View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985198#3985198

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985198