jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: upsert, same name siblings etc
Date Fri, 19 Aug 2011 15:57:24 GMT
On Fri, Aug 19, 2011 at 5:49 PM, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
> On 19.08.2011, at 17:45, Stefan Guggisberg wrote:
>> On Fri, Aug 19, 2011 at 5:14 PM, Lukas Kahwe Smith <mls@pooteeweet.org> 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
>>                    // 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.


> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org

View raw message