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. > > 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"); } cheers stefan > > regards, > Lukas Kahwe Smith > [email protected] > > > >
