When we planned the JBoss Cache 1.4 release weeks back, in addition to feature implementation, we have set out the goal to improve the overall cache performance. For PojoCache, that means performing the necessary benchmark first and making corresponding optimization. Now that 1.4beta is out, I am glad to report that we have achieved that objective!

 

In 1.4, first of all, the underlying replication layer has used more efficient marshalling to minimize the replication overhead. Second of all, much efforts have also been spent on refactoring the POJO attachment module such that it is more efficient in CPU usage and also reduction in replication message size.

 

To illustrate the performance of PojoCache, I have posted a Wiki article online to detail the comparison between TreeCache (a plain cache system) and PojoCache. Interested readers should refer it for more information.

 

Overall, it is expected that there would be a tradeoff between a plain cache system and a POJO cache one (that uses fine-grained replication) in terms of overall performance. The tradeff depends on the POJO object size, POJO lifetime, and also the update frequency and pattern. For example, if I have a small POJO with updates to most of the fields during a single request, we'd expect a plain cache system will be adequate. However, for other cases with medium to large size POJO and selected field updates, a POJO cache will not only have advantages in performance, it will also offer transparent, automatic replication! In one case that we studied in the article, e.g., PojoCache is 3.5 times faster than TreeCache. And if the POJO lifetime is longer, then we expect the speedup would be even greater!

 

Finally if you care not just performance but also want to maintain the object relationship during replication, PojoCache is then the cache that you should use!

 

Oh, in the upcoming JBossWorld in Vegas, I will have a session presenting more about PojoCache. Come join us there for the scoop and the fun!

-Ben Wang, Lead, PojoCache

 

 

I have been visiting Japan for almost two weeks now, first doing a public training, and secondly working with Japan OSS community here on JBoss web clustering benchmark. I will have more to say on the clustering benchmark effort in a later blog.

 

But last night, I have had a dinner with a group of people both from Japan JBoss mailing list folks (started by Fusayuki "Miki" Minamoto) and our partners in Japan. We had a total of 37 people crowded into a Japanese resturant to enjoy nabe (like seafood hotpot) and drinks. Food and atmosphere were great. But I was really touched to see the interest level there (not just for JBoss but also open source as a whole!)

 

Also as a result of last night's gathering, they have decided to start a JBoss User Group (JBUG) in Tokyo. That should provide an ideal platform for JBoss users to share and exchange information in Japan.

 

Lastly, Japan is probably not known to have big presence in OSS development, IMO. Projects that I am personally aware of are like Ruby and Javassist (and I am sure there are others that I have left out). But I was told in this trip that Seasar, a domestic DI/AOP container is very popular in Japan recently. I have to admit that this is my first time hearing about it.

-Ben

 

 

 

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 am currently working on the JBossCache 1.2.4 release. The release will be mostly focused on JBossCacheAop and also the features needed to support fine-grained http session replication. One of the outstanding feature is for JBossCacheAop to handle scoped class loader (that can be a common requirement in a web app.) But I will defer it to another blog when it is completed.

Here, I would like to talk about annotation. One of the features in release 1.2.3 is the JDK1.4-style annotation support for JBossCacheAop. It is documented in the release doco. But since I have people asked me the usage, I thought I illustrate it here with an example of the fine-grained http session replication.

Since annotation (both JDK1.4 and 1.5) is supported by the JBossAop, there is really no ground-breaking development to apply it to JBossCacheAop per se. But without annotation, a user will always need to specify the Pojo (in this case, Address and Person ) instrumentation in a jboss-aop.xml file such as:

<aop>
  <prepare expr="field(* org.jboss.test.cache.test.standAloneAop.Address->*)" />
  <prepare expr="field(* $instanceof{org.jboss.test.cache.test.standAloneAop.Person}->*)" />
</aop>

Because we use dyanmic aop, we require every field in your Pojo to be "aspectized". It can become tedious for user to list every single one of them. Annotation in this case will work perfectly.

To facilitate the use of annotation, I have provided an AopMarker and InstanceOfAopMarker interfaces acting as 1.4 annotation holder. Then there is a system-wide jboss-aop.xml that is located under resources directory to associate the annotation as follows:

<aop> 
  <prepare expr="field(* org.jboss.cache.aop.AopMarker->*)" />
  <prepare expr="field(* $instanceof{org.jboss.cache.aop.InstanceOfAopMarker}->*)" />
</aop>

Note that InstanceOfAopMarker denotes that any sub-class or interface implementation of the Pojo will be automatically instrumented as well.

With these, all a user needs to declare in the pojo becomes very simple. It is just one line of annotation code. For example,

/** 
 * @@org.jboss.cache.aop.AopMarker
 */
public class Address {...}

or

/** 
 * @@org.jboss.cache.aop.InstanceOfAopMarker
 */
public class Person {...}

Will declare both Address and Person Pojos to be "aspectized" under JBossCacheAop automatically (without using a jboss-aop.xml).

So let's say when the next release of JBossAS supports fine-grained http session replication, to use it: 1) you will specify in your jboss-web.xml (inside your web app) that the replication granularity is "FIELD", 2) then declaring your Pojo(s) like above, the http session replication will be fine-grained automatically.

For example, when you do:

Person ben = new Person(); 
session.setAttribtue("ben", ben); // This setup Pojo ben to be managed.
ben.setName("Ben");

Only the name field in object ben will be replicated!

Of course because this is a 1.4 construct, you will still need an annotation compiler step to pre-compile your Pojos. But when we support 1.5 native annotation in the future release, there will be no need for pre-compiling and it will become mostly transparent for application developers!