jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro Gomez <alejandro.go...@gmail.com>
Subject Re: Jackrabbit and multithread access to nodes | design motivations | jcr2
Date Fri, 18 Feb 2011 17:48:16 GMT
Thanks Stefan!

On Fri, Feb 18, 2011 at 2:28 PM, Stefan Guggisberg
<stefan.guggisberg@gmail.com> wrote:
> hi alejandro,
>
> On Fri, Feb 18, 2011 at 6:01 PM, Alejandro Gomez
> <alejandro.gomez@gmail.com> wrote:
>> Hi Stefan,
>>
>> I deleted the mysql tables and some files in the JKR repo, and now I
>> have a cleaner perspective of the facts I described in my first email.
>>
>> I ran a test that adds nodes to a same parent - concurrently with
>> different sessions-  and everything was right.
>>
>> I ran a test that adds a new string property to a same node  -
>> concurrently with different sessions -  and everything was right.
>>
>> I ran a test that modifies one property in one unique node -
>> concurrently with different sessions -  and I obtained:
>>
>> javax.jcr.InvalidItemStateException:
>> 00da5eb0-d7ea-41dc-aff4-2dd8940caab3/{}propertyToChange has been
>> modified externally
>
> this is expected and per design. see e.g. [0] for a related discussion on
> the mailing list. jackrabbit's behavior is compliant with the JCR 2.0
> spec ([1)).
>
> [0] http://www.mail-archive.com/users@jackrabbit.apache.org/msg16522.html
> [1] http://www.day.com/specs/jcr/2.0/10_Writing.html#10.11.6 Invalid States
>
> cheers
> stefan
>
>>
>> I hope this help to clarify my question.
>>
>>
>> Regards
>>
>> Alejandro Gomez
>>
>>
>>
>>
>> On Thu, Feb 17, 2011 at 11:10 AM, Stefan Guggisberg
>> <stefan.guggisberg@gmail.com> wrote:
>>> hi alejandro,
>>>
>>> On Wed, Feb 16, 2011 at 4:19 PM, Alejandro Gomez
>>> <alejandro.gomez@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I've been working with jackrabbit (2.x.x) more than a year, and some
>>>> questions arised when I faced the multithreading aspects of
>>>> Jackrabbit.
>>>>
>>>> I've found issues trying to add nodes (on different threads)  that are
>>>> children of a same parent.
>>>>
>>>> I've found issues trying to modify a node from concurrent sessions on
>>>> different threads.
>>>
>>> adding children to a parent node does modify the state of the parent node.
>>> so the situation is the same here as in your previous example.
>>>
>>> could you please elaborate what kind of issues/behaviour you're refering to?
>>>
>>>>
>>>> And after all, I did read a LOT of mailing lists archives, and I found
>>>> that some people encourage to implement explicit locking methods.
>>>>
>>>> My question is: What are the design/architecture motivations behind
>>>> this behavior?
>>>
>>> again, what behavior? could you please be more specific?
>>>
>>> cheers
>>> stefan
>>>
>>>> Is that related with some JCR 2 spec item? What would
>>>> be the "best practices" if any?
>>>>
>>>> I would LOVE if some of the core developers answer to this topic.
>>>>
>>>>
>>>> Thanks in advance to everyone!
>>>>
>>>>
>>>> Alejandro Gomez
>>>>
>>>>
>>>>
>>>> --
>>>> Lo que creas de los demás estará signado por lo que creas de ti mismo,
>>>> y del mismo modo los hechos de tu vida.
>>>>
>>>
>>
>>
>>
>> --
>> Lo que creas de los demás estará signado por lo que creas de ti mismo,
>> y del mismo modo los hechos de tu vida.
>>
>



-- 
Lo que creas de los demás estará signado por lo que creas de ti mismo,
y del mismo modo los hechos de tu vida.

Mime
View raw message