Question

I’m looking at using Apache Jackrabbit for a personal project but would like to know what are the advantageous/disadvantageous to using it versus a custom content repository or traditional database with content stored in the file system.

I’m not sure that I like the tree structure of the JCR so if you can explain the design decisions (adv/dis) behind that it would also help.

Answer 1

There are several benefits to using an existing JCR implementation, such as Jackrabbit or ModeShape. First and foremost, you immediately get lot of functionality for free:

• Hierarchical data storage – Lots of data is naturally hierarchical, and a JCR repository allows you to organize your data in the way that your applications will access it. Anything keyed by a URI, date/time, categories, or folder structures are natural fits for storing in a repository.
• Use a standard Java API – The JCR API is standard Java API with a TCK, meaning your applications can rely upon standard behavior and not be tied to a particular JCR implementation.
• Flexible schema enforcement – You can choose whether and where the node structure and property values are enforced by how you define and use node types.
• Data evolution – Your data structure will likely evolve over time, and JCR makes this very easy to do.
• Query and full-text search – Your applications can navigate through the data, or they can query for content independently of location. The JCR query languages are very rich, and they support full-text search.
• Transactions – You can control the transaction boundaries, which means that JCR Sessions can participate in JTA transactions controlled by your application or its container.
• Events – Your applications can be notified when nodes and/or properties are added, changed, or removed.
• Clustering – Scale your application by clustering the JCR Repository across multiple processes. Each implementation configure clustering differently, but they behave the same to client applications.
• Versioning – JCR includes a standard mechanism for versioning content. It might not be suitable to all use cases, but it is extremely handy when it is a fit.
• Locking – JCR includes a standard mechanism for short-term locks, which are useful when your applications need to ensure parts of the repository are updated by only one process.

If some of these features are important to you, then you should definitely consider reusing an existing implementation rather than rolling your own – otherwise you’ll be spending all your time implementing these kinds of features.

However, if none of these features fits your use case, then you should consider other data storage technologies:

• Relational databases work great when your data is very constrained, when your schema is not likely to change too often, or when your data is flat (lots of values of a few key types). (Note that many JCR implementations can store the content inside relational databases, so “I have to store my data in a relational database” is not really a good reason for your application to directly use a relational database.)
• Key-value stores work great when you need to store arbitrary values by unique keys, and all access is via gets and puts. The values are usually opaque to the store.
• Document stores are similar to key-value stores, except that the store is aware of the structure of the values. Some document stores support queries.
• Other storage technologies have their own sweet spot.

Other things to consider are whether you need or want an eventually-consistent database or a strongly-consistent database. It’s far easier to write many “conventional” applications against strongly-consistent databases, and in fact most JCR repositories (including Jackrabbit and ModeShape) are strongly-consistent.