Nuescheler explained how a content repository can fit into a typical web application. A JCR offers similar transactionality, scalability, and query support for structured data as a RDBMS but adds support for unstructured content, build in versioning, and "node-based" access control.
The Apache Jackrabbit project is an open source implementation of the JSR 170. InfoQ asked Nuescheler about the differences between Jackrabbit and CRX:
CRX can be considered as the commercialized Jackrabbit with a number of optimizations, added features, and easy to use packaging. CRX also features commercial grade support, release management and product management. Since featurewise Jackrabbit is the only complete opensource JCR implementation one can also expect the complete JCR featureset in CRX.
To increase performance for demanding environments, CRX 1.2 leverages the Apache Derby Persistance Manager. When asked about why CRX is using Apache Derby instead of Berkely DB Nuescheler responded:
a number of projects including Jackrabbit and also JDK 1.6 are using Derby. As a result it is a well tested and futureproof default persistance layer...
The new release of CRX also adds Active / Passive Clustering. This features a central, high-availability database server for permanent storage, and two CRX servers for non-permanent storage. Nuescheler commented:
active/passive clustering allows to hot failover from the active cluster node to the passive cluster node that is running on the same persistence layer for example a shared RDBMS. This allows us to avoid a single point of failure on the repository layer.This new clustering implementation improves cache management and performance in environments with large volumes of data and transaction loads.
We are working at the forefront of making the java content repository market viable for commercial grade applications. This is similar to what oracle did to the db market in the early days of sql. We are responding to the CRX community's needs and optimizing for those cases. This means for example that we support smart batch reads and batch writes (bundles) that enhance scalability drastically.
Community comments
Derby vs Berkley
by Alex Popescu,
Re: Derby vs Berkley
by Thomas Mueller,
Re: Derby vs Berkley
by Alex Popescu,
Derby vs Berkley
by Alex Popescu,
Your message is awaiting moderation. Thank you for participating in the discussion.
There are so many voices speaking about Derby and the decission to be included in JDK, so that I really wonder about the technical details. Also, I would say that the two cannot be compaired from licensing point of view and as far as I know this was the reason for Jackrabbit to work by default on Derby.
I would add that from my knowledge and our tests (indeed very custom), Berkley always performed better than Derby.
./alex
--
.w( the_mindstorm )p.
Re: Derby vs Berkley
by Thomas Mueller,
Your message is awaiting moderation. Thank you for participating in the discussion.
I don't know about Berley. But Derby is very slow compared to other databases for simple queries. This 'performance problem' is there since a long time. I published performance results around 1998 (when the product and company was called Cloudscape), but then somebody told me I 'must remove them'.
See also my current performance test results (with source code) at H2 Database Engine / Performance.
Re: Derby vs Berkley
by Alex Popescu,
Your message is awaiting moderation. Thank you for participating in the discussion.
Berkley is somehow different from normal RDBMS, so I guess it wouldn't make much sense to include it in your reports. However, for JCR, and I guess can refere here both Jackrabbit and CRX, Berkley should be included in performance tests. At least this is my opinion.
But, there may be another details for this decission that are not about performance.
./alex
--
.w( the_mindstorm )p.