On 19.08.2011, at 17:45, Stefan Guggisberg wrote: > On Fri, Aug 19, 2011 at 5:14 PM, Lukas Kahwe Smith <[email protected]> > wrote: >> Hi, >> >> So I am seeing behavior in production where I end up with same name >> siblings, the chances for that are pretty slim since its inside an import >> that checks if for the given path the data exists before starting the import >> which takes just a few ms. > > there's either a bug in your client code or the node in question has > been created in the meantime by another session. > >> >> What is stranger is that locally I cannot get same name siblings ever. Even >> if I disable the up front check all I get is an ItemExistsException. Is it >> because in production I am using MySQL for persistence and locally I am >> using the File System? Aka File System just doesnt support same name >> siblings? > > no. > > you're most likely using different node types on the parent node. > whether a node can have SNS-child nodes is governed by the its (i.e. > the parent node) node type.
no .. the node type is identical .. in both cases its nt:unstructured so this is really puzzeling me then .. why do i get an exception when i try to create a node with the same path on an nt:unstructure parent? >> If so it would be great if such feature different would be mentioned on: >> http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ#LocalFileSystem: >> >> At any rate I do not want same name siblings. I guess I can create a custom >> node type to prevent this from happening. But what I wonder is if I can then >> also somehow ensure that if I try to add a node to a path that already >> exists that it simply updates the content (with a new revision) instead, >> kind of a versioned upsert? > > that's unfortunately not supported. > >> Or will I always have to implement something like this locally by locking >> the parent to prevent concurrency? > > that's one possibility, yes. alternatively you could also serialize > the node creation code or use something like this: > > Node parent = ...; > Node child = null; > if (!parent.hasNode("child")) { > try { > child = parent.addNode("child"); > session.save(); > } catch (RepositoryException e) { > // the node might just have been created by another > session, > // try again > child = parent.getNode("child"); > } > } else { > child = parent.getNode("child"); > } yeah .. kind of pessimistic vs. optimistic locking. not sure if the layer that i am using for access can be made to deal with the optimistic locking situation, as it kind of wants me to do a full rest of the "transaction" whenever i encounter an issue. BTW: dont think this is important in this context but I am using the Davex APi via Jackalope (PHP implementation of JCR). regards, Lukas Kahwe Smith [email protected]
