Fine-grained ejb3 SFSB

[ben.wang]

(I have written this initial spec a while ago and checked into cvs. Now, I am publishing it here to solicit further comments. If resource allocation is not an issue, we'd start the implementation starting March.)

Goal: To enable fine-grained replication in JBoss EJB3 SFSB state replication. Currently, we support ejb3 SFSB replication using JBossCache. E.g., a user can annotate her SFSB with @Clustered and it will be replicated automatically. But it is replicated in a whole-sale fashion.

User, however, will need to do isModified() API to have fine-grained control of the bean replication. By using TreeCacheAop (aka POJO Cache), there will be no need of user implementing isModified flag. POJO Cache will track the field replication automatically (if there is one).

There is another side benefit that the new fine-grained replication can support object relationship inside the SFSB fields.

Note that we will support fine-grained http replication officially in 4.0.4 release. So some of the enhancement there for JBossCache will carry over here, e.g., activateRegion to support ejb lifecycle (deploy/undeploy) and also marshalling for classloader scope.

Steps: Here are the main tasks needed.

1. There is an additional annotation @PojoCachable that declares this SFSB to be instrumented. We need this for aop to aspectize the SFSB.
2. (Optional?) Determine a consistent annotation flag, such as "FIELD" tag inside the clustering annotation, e.g., @Clustered(ReplType=FIELD) (with ReplType default being SESSION)
3. Requires JBossCache 1.3 that supports 1.5 JDK with annotation
4. Depending on whether "FIELD" is specified, we should do two different paths:
a) If set, pojo cache API is used (putObject and removeObject). We need to instrument the SFSB first either on the fly (based on PojoCacheable annotation), LoadTime mode, or it can be pre-compiled, CompileMode. Then, we need to do putObject and removeObject for pojo cache operation instead of regular ones. Maybe we should use different SessionContext that stores the SFSB. One for regular and the other for FieldBased, like we did with Session in Tomcat.

b) If not, regular cache API is used (e.g., pure, remove). Then replication is "SESSION" based. User will need to implement isModified for fine-grained control.

5. For fine-grained, it should mimic the implementation in http session, e.g., issues of marshalling, etc.

6. Use StatefuleReplicationInterceptor for batch tx control. The counter part of ClusteredValve in Tomcat.

7. Configuration. Should not change much. User will need to annotate by itself on the SFSB POJOs.

Issues: There are couple possible issues need to be resolved.

1. passivation. Currently Bill has another passivation layer on top of JBossCache. What is the impact?

2. SFSB lifecycle. This should be supported already with the latest JBossCache, e.g., activateRegion for deploy/undeploying

[belaban]

1. Why do we need another annotation tag @PojoCachable ? Why not reuse @Clustered, and possibly add another attribute to it (fineGrained=true/false) ?

2. Okay, this answers #1. I don't think we need @PojoCachable then

4a. Could we not simply use putObject(), removeObject() etc *all the time* ? If the object is not aspectized, then we'd fall back to simple serialization, won't we ?

[ben.wang]

1. Well, I am not yet sure if we can skip @PojoCacheable. To instrument the POJO, JBossAOp need annotation. So @Clustered will do. But we need @Clustered(fineGrained=true) to trigger instrumentation. That I don't see how. I will check with Kabir anyway.

2. Yes, we can use putObject and it will fall back to put if it is nor "aspectized". But it has some additona l overhead. So a simple switch may be better.

[smarlow]

Here are some of my thoughts:

1. If we are running in a large cluster (lets say 512 nodes), it would be nice if we could batch up the replication of attribute changes. This might be done asynchrounously in the background (perhaps using underlying capabilities or implemented in SFSB replication code). I suggest that we think about this as its a nice to have.

2. If we configure the underlying Cache to be async, clearly sfsb attribute changes will replicate in the background. If the Cache is configured to be replicated synchronous, do we wait for acknowledgement on the cache put? Or do we let the underlying transport defer the transmission?

3. I don't remember reading anything about sfsb attribute changes being transactional. If sfsb attribute changes are not transactional, we probably need to bracked our cache.put calls with something like this:

 IF HAVE CURRENT TRANSACTION
 SUSPEND TRANSACTION;
 Cache.Put("Attribute Name", value);
 IF SUSPENDED TRANSACTION
 RESUME TRANSACTION;

We need to suspend the active transaction as we don't want the sfsb changes to be transactional when that is not intended by the application writer.

4. Consider supporting of transactional sfsb changes. This would be really cool IMHO. We simply don't bracket the sfsb cache.put calls and JBossCache does the heavy lifting for us.

5. I don't think we need to worry about the Cache.get calls running inside of a transaction. So they don't need to be bracketed with tx.suspend + tx.resume calls.