jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Weighill-Smith <phil.weighill-sm...@volantis.com>
Subject Re: concurrent writes
Date Mon, 12 Jan 2009 09:39:41 GMT
I have a (perhaps dumb) question about one of the points raised in the
linked issue (JCR-1552):


Here you state that creating a child node is like a SQL INSERT, whilst
setting a property is like a SQL UPDATE; the implication is that a node
is like a row and a property is like a column.

In that case, is it possible to set a property during the creation of a
node? If not, then surely setting a property the very first time should
be equivalent to a SQL INSERT - after all an INSERT allows all columns
to be assigned values during initial creation of the row; you are not
required to do both an INSERT and an UPDATE.

Or is it that the JCR API structure simply prevents an implementation
from handling this case (seems unlikely)? (Yes, I can see that it may
require the implementation to maintain additional internal state to
handle the case, but it seems doable.)

My concern is that whilst at the JCR level locking may be a nice and
easy solution this doesn't always fit well with clients; we have an
application using a non-JCR content repository that essentially does
optimistic locking; we allow any number of users to perform concurrent
viewing and/or editing of nodes and on save handle conflicts by allowing
automatic and (when needed) manual merges.

We are looking to leverage JCR and Jackrabbit in an updated version of
the application, so this behaviour is relatively important to us - it
needs to be clearly documented and consistent (plus, obviously,
conformant with the specification). I would think that we can work
around it either way with a combination of version detection and
short-term node locking during write.

Phil :n.

On Tue, 2009-01-06 at 10:17 +0100, Jukka Zitting wrote:

> Hi,
> On Mon, Jan 5, 2009 at 2:16 PM, Torsten Curdt <tcurdt@apache.org> wrote:
> > Thanks! That links was very interesting ...not sure it gives a final
> > answer though.
> Yeah, we never got around to going through the code based on the
> results of that discussion.
> You may want to file a bug report about the setProperty behaviour. A
> set of concurrent setProperty calls (with no Node.addNode or
> Node.remove calls in between) should IMHO never fail with an
> InvalidItemStateException.
> BR,
> Jukka Zitting

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