jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek" <aklim...@day.com>
Subject Re: concurrent writes
Date Mon, 12 Jan 2009 11:45:51 GMT
I think the SQL comparison was a rough one, not one to take as 100% the same.

In the JCR API, a transaction can contain anything, it will happen
once you save. So you can add a node and save it, but you can also add
a node, add properties to it and save. Same for modifiying data by
getting a node and changing or adding properties on it.

If you don't use locking, Jackrabbit employs an optimistic strategy
(it's not mandated by the standard, see also copy-on-write vs.
copy-on-read [1] [2]). This means you will get an exception on save if
there is a conflict from another session. This allows you to handle
that issue in the application.

[1] http://wiki.apache.org/jackrabbit/JcrSpecImplementation
[2] http://www.day.com/specs/jcr/1.0/


On Mon, Jan 12, 2009 at 10:39 AM, Phil Weighill-Smith
<phil.weighill-smith@volantis.com> wrote:
> I have a (perhaps dumb) question about one of the points raised in the
> linked issue (JCR-1552):
> https://issues.apache.org/jira/browse/JCR-1552?focusedCommentId=12592051#action_12592051
> 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

Alexander Klimetschek

View raw message