This is a todo that lists issues that we discussed on 4/26/06 for the pojo clustering annotation (http://wiki.jboss.org/wiki/Wiki.jsp?page=PojoClustering). Eventually, we will merge these conclusion back to that page and publish it.

1. Change @Clustered annotation back to @Replicated such that we have a clear separation of client- and server-side clustering

2. Move load balance policy to @Remote annotation since it should belong on the client side.

3. Issue of how to create a proper client interceptor stack if we seprate the client and server.

4. Elevate @Singleton annotation with singletonPolicy attritubes for configuration

5. Have a pseudo code to illustrate all these annotation usage

6. Merge @ClusterConfig annotation back into @Clustered

7. Event type include object lifecycle (just in case when it is created on the replicated node)

8. how much of replication tier aspects should be allowed to be configurable at the POJO level. E.g., replication mode seems like a good idea. But how about buddy replication?

Bela's notes

Sample code

We need to come up with some sample code that shows how pojo-based programming looks like. Especially of interest is

• Annotation of Pojos

• Life cycle

• Creation, deletion, lookup of Pojos. E.g. you create a Pojo on node A, it is replicated over to node B, how does one get a reference to that Pojo on node B ?

• Eviction (?)

Annotation

A Pojo could look like this:

@Remote(policy="sticky") // creates clustered proxy
@Replicated(mode="async", singleton="false") // replicates the Pojo across all nodes in a cluster
public class Pojo {
   int age;
   String name;
   @Transient // don't replicate hash !
   int hash;
   Address addr;
   @Serializable // don't instrument hobbies, use serialization to replicate !
   List  hobbies;
}

EJB3, MC

Can we integrate into EJB3 ? If so, how ? Could we for example use EntityManager, and its detach() and merge() methods ? E.g. detach() means that we don't persist changes, but we could also use it to mean we don't replicate changes after detach() is called. So we could integrate tightly with EJB3 semantics.

However, if we wanted to make a pojo non-persistent by calling detach() (similar to JDO's makeTransient()), but would still want to replicate changes, then we'd have to call another method.

We probably have to come up with our own EntitManager-like class, which has methods makeReplicated() and makeLocal() (equivalents of putObject() and removeObject()). They could be called standalone, but integrated into EJB3, detach() would for example call makeLocal().

What are the container we will integrate with ? I suggest MC first (is EJB3 a container at all in the first place ?)

Callbacks

How do we observe changes to a pojo ? This may not be clustering-specific, e.g. we could use the Observer/Observable framework already in place thanks to JBossAOP. Here's how it would be nice to register as an Observer:

@Observable
public class MyPojo {
}
...

MyPojo pojo=...;
Observable obj=(Observable)pojo;
obj.register(new Observer(pojo)); // Observer has all the callbacks, such as fieldModified() etc

Comment from Ben

Currently, we use this pattern inside http field replication to observe the field changes. Using this give user lots of control on how he wants to use the event. However, then he will needs to get into AOP land, that's the downside a little bit (e.g., setting up SubjectImpl mixin, implementing Subject interface, and also the interceptor). Maybe, we simply provide a POJO event notification for subscription and hide the AOP nature underneath.

Singleton

Failover would have to use an interceptor similar to RetryInterceptor (might use Discovery service)

Singleton and buddy replication are 2 attributes of the @Replicated annotation

Changes to behavior at runtime

Can we change async --> sync replication at runtime ? We can already make a replicated object local by calling MyManager.makeTransient(pojo) (which essentially calls PojoCache.removeObject()), can we do this for other modes as well ?