You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Alejandro Gomez <al...@gmail.com> on 2011/02/16 16:19:36 UTC
Jackrabbit and multithread access to nodes | design motivations | jcr2
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.
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? 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.
Re: Jackrabbit and multithread access to nodes | design motivations | jcr2
Posted by Alejandro Gomez <al...@gmail.com>.
Thanks Stefan!
On Fri, Feb 18, 2011 at 2:28 PM, Stefan Guggisberg
<st...@gmail.com> wrote:
> hi alejandro,
>
> On Fri, Feb 18, 2011 at 6:01 PM, Alejandro Gomez
> <al...@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
>> <st...@gmail.com> wrote:
>>> hi alejandro,
>>>
>>> On Wed, Feb 16, 2011 at 4:19 PM, Alejandro Gomez
>>> <al...@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.
Re: Jackrabbit and multithread access to nodes | design motivations | jcr2
Posted by Stefan Guggisberg <st...@gmail.com>.
hi alejandro,
On Fri, Feb 18, 2011 at 6:01 PM, Alejandro Gomez
<al...@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
> <st...@gmail.com> wrote:
>> hi alejandro,
>>
>> On Wed, Feb 16, 2011 at 4:19 PM, Alejandro Gomez
>> <al...@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.
>
Re: Jackrabbit and multithread access to nodes | design motivations | jcr2
Posted by Alejandro Gomez <al...@gmail.com>.
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
I hope this help to clarify my question.
Regards
Alejandro Gomez
On Thu, Feb 17, 2011 at 11:10 AM, Stefan Guggisberg
<st...@gmail.com> wrote:
> hi alejandro,
>
> On Wed, Feb 16, 2011 at 4:19 PM, Alejandro Gomez
> <al...@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.
Re: Jackrabbit and multithread access to nodes | design motivations | jcr2
Posted by Stefan Guggisberg <st...@gmail.com>.
hi alejandro,
On Wed, Feb 16, 2011 at 4:19 PM, Alejandro Gomez
<al...@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.
>