static field replication in PojoCache

[ben.wang]

I am trying to scope out the requirement for the static field replication. Here are what I have:

1. Create a @Replicatable field annotation so user can annotate the POJO to designate the static field for replication, e.g.,

@org.jboss.cache.pojo.annotation.PojoCacheable
public class POJO
{
 @org.jboss.cache.pojo.annotation.Replicatble
 public static int someStaticVar;

 ...
}

such that

POJO.someStatic=10

will trigger the replication.

2. Only support the static variable of either Primitive or Serializable. I.e., can't support another "aspectized" POJO.

3. The fqn name for the static field varialbe is global and is known a priori, e.g., in the above case, someStaticVar will be stored under:

/__JBoss_Static_/POJO/someStaticVar

4. The static variable will be stored under the cache during POJO initialization (even when no POJO has not been put into the cache yet!)

5. And finally, there can be only ONE PojoCache instance per VM! This is needed to follow the normal Java semantics. Furthermore, if we have multiple cache instances, which cache instance are we going to store the static variables under?

Of course, the last requirement is more restrictive and more importantly make the unit testing difficult.

[genman]

Couldn't you have statics work like this:

PojoCache c = ...;
c.registerClass(POJO.class);

I suppose also you could do some tricks with the classloader, so a classloader would have a PojoCache attached to it. And at the time the class is loaded, it gets registered.

[ben.wang]

Sorry, I don't get it. What will registerClass do to POJO? To start replication?

Attach to the class loader idea is fine but IMO is making the process more complicated than it should be.

[genman]

Why are 4 and 5 even good ideas, let alone "requirements"?

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.

To be fair, I'm not really involved with this feature at all. I'm not the customer. But here are what I believe are "requirements":
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.
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.

[belaban]

#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 !

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

#3 Sure. Implementation issue correct ?

#4 Or lazy, whatever. Implementation issue again

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

[ben.wang]

"genman" wrote:
Why are 4 and 5 even good ideas, let alone "requirements"?

Yeah, sorry, just missed typing the "restriction" part.

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

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?

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.

[ben.wang]

#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.

#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?

#3 Sure. Implementation issue correct ?

#4 Or lazy, whatever. Implementation issue again

Yes, implementation issues.

#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.

[belaban]

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.
 ...
}

I think this is not intuitive: @PojoCacheable replicates *all* variables, so static vars should be included.
You can exclude static vars using the transient keyword or @transient annotation.

#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?

Can we at least try before we give up ? :-) I don't (currently) see why static vars should only be of primitive types... So, okay, we can create those instances but only replicate them once we have been fully initialized.

#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.

Why should only 1 PojoCache be allowed to have static var replication inside the same VM ? This sounds like an arbitrary restriction...

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.

Still much better than @PojoCacheable, which is horrible

[ben.wang]

I think this is not intuitive: @PojoCacheable replicates *all* variables, so static vars should be included.
You can exclude static vars using the transient keyword or @transient annotation.

But keep in mind that by default, we skip replicating static, final, and transient now. If we want to change the default to replicate static field, question is how often people want to replicate static field? If often, then yes, default is good. But otherwise, default may not be that good.

And what about final field default?

Why should only 1 PojoCache be allowed to have static var replication inside the same VM ? This sounds like an arbitrary restriction...

Yeah, agreed then. I am still thinking if there is a better way to support it other than explicit api.

Still much better than @PojoCacheable, which is horrible

I will create a new thread to discuss this then.

[belaban]

But keep in mind that by default, we skip replicating static, final, and transient now. If we want to change the default to replicate static field, question is how often people want to replicate static field? If often, then yes, default is good. But otherwise, default may not be that good.

By default we need to replicate static fields, don't replicate final and transient (or @transient) fields.

[belaban]

Yeah, agreed then. I am still thinking if there is a better way to support it other than explicit api.

Yes, agreed. I don't see the need for this API.

[ben.wang]

OK, let me try to propose from step 1 again on a newer approach after collecting these feedback. Let's first list the example POJO though:

public class POJO
{
 public static int someStaticVar;

 @Transient
 private static int anotherStaticVar;

 ...
}

1. static field replication is on by *default*. If a user wants to turn it off, he can annotate it with @Transient tag as in the above code snippet.

2. There will be no new API introduced. Instead, we will rely on the usual POJO attach/detach to trigger static field replication. E.g.,

...
// First attach will trigger static field replication as well.
cache.attach("id", pojo);
...
cache.someStaticVar = 20; // This will get replicated.

// last attach will remove the static field.
cache.detach("id");

2a. Again we will store the static variable under a special area, /__JBoss_Static__/.

2b. We will do reference counting to keep track of how many POJO there are associating it (such that we know when to remove the replicated static field).

I think this is much cleaner approach. What do you think?

[ben.wang]

BTW, the corresponding Jira is:
http://jira.jboss.com/jira/browse/JBCACHE-726

[belaban]

Absolutely, +1. This is in line with the rest of our semantics

[manik]

Can we at least try before we give up ? :-) I don't (currently) see why static vars should only be of primitive types... So, okay, we can create those instances but only replicate them once we have been fully initialized.

I agree that we should not just support static primitives. I can foresee many object models that will use static objects. And I don't see why this should be an issue anyway.