jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Neale" <michael.ne...@gmail.com>
Subject Re: Comparing an RDBMS to JCR
Date Mon, 02 Oct 2006 12:36:20 GMT
Well you have to ask if you want to use a CMS API, (or even a CMS) versus
roll-your-own using a DB directly.

A CMS and JCR provide a lot of value which you may not appreciate until you
try to replicate some of the features in a DBMS based system. I am only new
to JCR myself, but mostly I am finding that the "quirks" that are there make
me use it in a way that is optimal for managing *content* - ie people who
know more about content then me. I like that "opinionated" approach, as I
don't know enough about CMS to build an API myself, so am happy to be shown
the way by JCR.

On 10/2/06, behrangsa <behrangsa@gmail.com> wrote:
>
>
> Doug,
>
> Thanks for the reply. Does it imply that using JCR has a __serious__
> performance penalty compared to direct access to the database via JDBC,
> and
> even using ORM tools such as EJB3?
>
> BTW - There's a good comparison of JCR to File Systems and DBs available
> at
>
> http://www.day.com/site/en/index/products/content-centric_infrastructure/content_repository/crx_faq.html
>
> But I am still confused as to when one should consider using JCR* as a
> fundamental component of an enterprise project? For what kind of projects
> does it make sense to use JCR? Once we consider using JCR, should we
> store/retrieve everything via JCR? Or only a portion of the project should
> be so?
>
> *JCR or any other CMS (?) API
>
> Regards,
> Behi
>
>
> Doug Douglass-2 wrote:
> >
> > Behi,
> >
> > I think the only thing you're missing is locking. Many (most) RDBMS have
> > some level of built-in/implicit locking of the table or, better yet the
> > row,
> > for write operations. This is not true of JCR,  you must explicitly
> > lock/unlock your nodes to prevent concurrent update attempts.
> >
> > HTH,
> > Doug
> >
> > On 10/1/06, behrangsa <behrangsa@gmail.com> wrote:
> >>
> >>
> >> Hi,
> >>
> >> The concurrent update capability of JCR is a little bit confusing to
> me.
> >>
> >> In an RDBMS, when I execute the following code sinppet simultaneously
> by
> >> a
> >> few threads, no problem rises:
> >>
> >>   tx.being();
> >>   executeUpdate("insert into positions(id, name, parentId) values (?,
> ?,
> >> 1)");
> >>   tx.commit();
> >>
> >> In JCR, the equivalent to this seems to be:
> >>
> >>   tx.begin();
> >>   Node positions = session.getRootNode().getNode("positions");
> >>   Node pos = positions.addNode("position");
> >>   pos.setProperty("name", "some name");
> >>   tx.commit();
> >>
> >> But apparantly this throws an InvalidItemStateException (am I right?)
> >> when
> >> multiple sessions concurrently execute this snippet of code. If this is
> >> true, then how can one handle the aforementioned SQL operation in JCR?
> >>
> >> Regards,
> >> Behi (via Nabble :-)
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Comparing-an-RDBMS-to-JCR-tf2366850.html#a6593713
> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Comparing-an-RDBMS-to-JCR-tf2366850.html#a6594059
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message