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
|