On Fri, Aug 19, 2011 at 5:49 PM, Lukas Kahwe Smith <[email protected]> wrote: > > 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).
erm, sure it is import. my comments were based on jackrabbit (core)... i am not familiar with your stack. cheers stefan > > regards, > Lukas Kahwe Smith > [email protected] > > > >
