Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Message-ID: <6594059.post@talk.nabble.com>
Date: Sun, 1 Oct 2006 16:39:07 -0700 (PDT)
From: behrangsa <behrangsa@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: Comparing an RDBMS to JCR
In-Reply-To: <3a9670a0610011609v7b1a376eg90fe93057ab862db@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <6593713.post@talk.nabble.com>
 <3a9670a0610011609v7b1a376eg90fe93057ab862db@mail.gmail.com>


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.