I've got a number of treats for you guys today.
Firstly, I've just released 3.0.0 BETA1. The public API is finally stable and all major features are in. A few minor bugs and performance tweaks (and documentation) pending, this is pretty much what Naga will look like. Expect it to rock your world! ;)
Second, after much discussion with the community, I have decided to make Naga API compatible with 2.x releases (Poblano, Alegrias and Habanero). This means a somewhat more cluttered API and a pile of old, deprecated methods, but at least it means you can just drop in a Naga jar into an app compiled against 2.x and expect things to work. You could then update your code to use more "current" APIs at your leisure. Keep in mind though that Naga runs with MVCC by default. If you wish to use PESSIMISTIC locking (the previous default) please make sure you specify this explicitly in your config file.
Finally, at long last, I have pretty pictures for people. Benchmarks comparing 3.0.0.BETA1 against 2.2.0.GA (released just last weekend), and 2.1.1.GA. And, for kicks, against the latest EHCache release as well. So far I just have the standalone benchmarks. Expect replicated benchmarks coming your way very soon.
So, lets get started. Download the release in the usual place, feedback on the forums please. The more feedback the better, it helps us make JBoss Cache a better product. The changelog is in JIRA.
Notable features include:
- a new batching API (JBCACHE-991)
- the ability to persist transient state upon startup when fetchPersistentState is false (JBCACHE-131)
- redesigned eviction, where you can now provide not just policies on how to select nodes for eviction, but also how that eviction behaviour is manifested (JBCACHE-1398). In plain English, this means you can now set the cache up such that nodes are completely removed upon eviction.
As for benchmarks, these were generated using the Cache Benchmark Framework that I wrote. I actually encourage people to download the framework and perform these benchmarks on their servers as well to help validate my numbers. The benchmarks were performed on the JBoss clustering lab, with the following configuration:
- Server running RHEL 4 and Sun JDK 1.5.0_11 with default settings
- Max heap size of 2GB
- 4 Xeon CPUs with 4GB of RAM
(smaller is better)
Write (PUT) performance
(smaller is better)