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/7.1.3.4_Seeing_Changes_Made_by_Other_Sessions.html Regards, Alex On Mon, Jan 12, 2009 at 10:39 AM, Phil Weighill-Smith <[email protected]> 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 <[email protected]> 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 [email protected]
