Daniel Doubleday wrote:
My application includes many use cases where it has to be able to add many
'n' in an 1-n relationship concurrently. Think of a blog where the the 1 is
the blog entry folder and the n's are the entries. Many users will be adding
entries at the same time. In an RDBM System that's no bi deal since the blog
entry folder never has to be updated when a new entry is added.
With JCR the child node references are stored in the parent node. Thus the
locking problem. I think that's simply the price of JCR and my app is not
suitable.
imo a blog is the perfect application for JCR. it is inherently
hierarchical if modeled carefully. Using a well designed hierarchy not
just helps representing content on the web using URLs but also helps
solving your concurrency problem. Unlike a RDBMs blog entries don't
have to be stored in a flat table. Simply store them the way you
usually access them: by their date
so, I would structure them the following way:
+ blogs
+ user1
+ 2006
+ 09
+ 24
+ f2f-at-almaden
+ 10
+ 03
+ jcr-is-great
+ user2
+ ...
and since nowadays we want to be restful those blogs are easily mapped
to urls like:
http://www.jcrblog.org/user1/2006/10/03/jcr-is-great.html
moreover displaying the blogs written in september 2006 by user1 is as
simple as iterating over the child nodes of /blogs/user1/2006/09. no
need to run a query.
and finally your concurrency problem disappeared too. Unless the very
unlikely case occurs that a user enters two blog entries at the same time.
IMO JCR is closer to a object oriented than a relational database,
hence the data structure and the node types should be modeled with
this in mind.
If you still have concurrent changes on a node you can use the utility
class org.apache.jackrabbit.util.Locked, which helps you to
synchronize access to a lockable node with just a couple of lines of code.
regards
marcel
