jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Shiner" <rabbit....@googlemail.com>
Subject Re: Concurrent modifications ...
Date Fri, 21 Apr 2006 14:44:36 GMT

Thanks for your quick response,


On 4/21/06, Marcel Reutegger <marcel.reutegger@gmx.net> wrote:
> Robert Shiner wrote:
> > Yup, that seems to work, thanks.  Although not against 1.0, I needed to
> > checkout and build the latest snapshot.
> oh, you are right. thanks for pointing that out. the related issue is:
> JCR-336.
> > Does anyone know when the next release with the lock fixes in is due?
> >
> > Also I have a question around applying the lockable mixin.
> >
> > I understand that a node can not be locked unless it has the lockable
> mixin
> > applied.
> IMO a good node type design already has the mix:lockable mixin in its
> definition for nodes that should be lockable. with such a design it is
> then not necessary for an application to add mixins on node instances.
> > If I want to lock a node, but I'm not sure whether it already has
> > the lockable mixin, how can I check and then add the mixin in such a way
> > that is safe in a concurrent environment?
> node.isNodeType("mix:lockable") will return true if it is lockable.
> you need to aquire a deep lock on a lockable ancestor of that node then
> you can add a mixin to the desired node. but as I pointed out before I
> suggest you do not add mixins to individual node instances but define
> lockable mixins in your type hierarchy.
> regards
>   marcel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message