Skip navigation
2005

Ben Wang's Blog

September 2005 Previous month Next month

 

JBoss Cache 1.2.4 beta has been released. As usual, you can use it in two modes: plain cache (through TreeCache component) or so-called fine-grained POJO cache (through TreeCacheAop component). Both components are in-memory, replicated, transactional, and persistent as well. You can download it here, or check out the online doc. I thought I go over the key features here.

 

1.2.4 started out as mostly a POJO cache release since we have major enhancement for the TreeCacheAop component. First of all, I have totally revamped the "distributed" object-graph model. By "distributed", I meant automatic preservation of object graph relationship during either replication or persistency (through the cache loader).

 

Previous model has problems to handle object-graph relationship when there is complicated interaction between POJOs and Collection classes, especially when it is recursive (or cyclic). In the current model, pure object reference counting is used such that complex interactions can be handled directly without problem. The design discussion was carried out here

 

To illustrate that, there are two "real-life" JUnit examples under tests/functional/org/jboss/cache/aop/intergrated directory. I am also preparing an article to further describe the full functionality. So stay tuned!

 

In addition, I have re-written the TreeCacheAop documentation to cover the various topics in more details.

 

On the plain cache side, we have added overflowing (passivation/activation) feature. For example, with cache loader, eviction will persist the evicted data into a persistent store (can be Berkeley- or JDBC-DB). So next time the data is retrieved, it will be from the persistent store. This feature is acting simliar to ejb passivation/activation. Note that this feature will be basis for future http session clustering passivation, for example.

 

Finally, we have added a marshalling mechanism for JBoss Cache to handle replication under a scoped class loader. Class loading can be an irritating problem when an application is run under AS. This is especially true when JBoss Cache is deployed since the JGroups replication layer has no notion of an application class loader! What we have done is to provide a registry for applications to register their associated class loader to JBoss Cache so the data can be unmarshalled correctly.

 

For the full details, you can visit this Forum post.

-Ben
I have blogged previously on the new JBoss Clustering roadmap and how it has been re-architected. To give more details, JBoss Clustering mainly consists of 3 main parts:

  •  

    EJB client-side cluster interceptor that has intelligence of cluster toplogy and load balance policy. One of the strength of JBoss cluster interceptor is its transparency to the client. That is, configuration is done on the server side and downloaded to the client at runtime. As a result, client is not even aware of it is using clustered service!

     

    For the existing EJB2.1, we have HA-RMI that runs top of the RMI layer. But for EJB3.0, Bill Burke has implemented HA-Remoting that runs on top of JBoss Remoting. It further provides flexibility on the selection of transport layer mechanism.

  • State replication. Previoulsy we have different state replication mechansim to deal with http session and sfsb, for example. Now, we will use JBossCache for everything that is involved with state replication. Modules that currently have been/are transitioning to using JBossCache are:
    • Http session (including SSO). This has been introduced since AS 3.2.6 that is bundled with the Tomcat module.
    • EJB3.0 SFSB. This has been introduced in EJB3 Beta release.
    • EJB3.0 Entity. This has been introduced in EJB3 Beta release.
    • DistributedState. This is an internal component that is currently implemented by Scott Marlow (from Novell) in AS 5.0
    • HA-JNDI. This is the JBoss clustered jndi server (that can be released separately in the future.) It is currently implemented by Jerry Gauthier (from Novell) in AS 5.0
  • Distributed RPC. There are times when a moudle needs to execute distributed RPC call. For example, in JBoss HA-JNDI, sometimes we will need to ask the other local jndi servers to see if they hold a specific EJBHome stub. Currently, HAPartition is the distributed RPC layer.

 

To sum up all these relationship, below is a figure illustrating the new layered component architecture of JBoss Clustering. You can see that the clustering stack from the bottom up that starts with JGroups, then with JBossCache and HAServices, and so on.

 

 

So what are the advantages of this layered approach, you ask? Well, for one, since stack modules can be independently released, it is much easier to maintain. For example, a bug fix in JBossCache only involves with a patch of jboss-cache.jar.

 

In the same token, when JBossCache implements buddy replication feature, that means JBoss Clustering will be able to support sub-paritioning of cluster group and thus promote large number scalability. In another example, Hany Mesha (also from Novell) has recently implemented the cache overflowing feature in the upcoming JBossCache 1.2.4 release. It will be used for http session and ejb clustering passivation/activation features next.

 

Finally, the figure below shows the mutual release dependency of JBoss Clustering components and their main features.

 

 

Here are highlights of some of the key features in different components:

  • JGroups 2.3
    • Channel multiplexing. This enables different users of JGroups to share a single JChannel. As a result, it can simplify and consolidate all the JGroups configuration used by various components.
    • Partial state transfer. Needed to guarantee state integrity.
  • JBossCache 1.2.5 & 1.3
    • Optimistic locking. Potentially can increase concurrency during short transaction span.
    • Buddy replication. Only replicated on a configurable sub-group.
  • AS 4.04 & 5.0
    • HA-JNDI. Clustered jndi server using JBossCache.
    • Fine-grained replication for SFSB and http session.