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: Jackrabbit and multithread access to nodes | design motivations | jcr2
Date Thu, 17 Feb 2011 14:10:09 GMT
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?


> 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.

View raw message