jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Douglass" <douglass.d...@gmail.com>
Subject Re: Comparing an RDBMS to JCR
Date Sun, 01 Oct 2006 23:09:03 GMT
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.
>
>

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