You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Paco Avila <pa...@git.es> on 2006/08/11 12:39:00 UTC
Re: [jira] Commented: (JCR-533) failing Node.lock() might leave
inconsistent transient state
El vie, 11-08-2006 a las 11:18 +0200, Angela Schreiber escribió:
> Paco Avila (JIRA) wrote:
> > [ http://issues.apache.org/jira/browse/JCR-533?page=comments#action_12427471 ]
> >
> > Paco Avila commented on JCR-533:
> > --------------------------------
> >
> > I've reading the specification and can't find any reference to transient
> > session in Node.lock(). Do you mean that Node.lock() don't modify transient
> > session because it performs a Node.save() internally (there is no need to call save)?
>
> Locking methods (as well as most versioning operations) in
> fact do modify the transient space even if save() is called
> immediately afterwards.
> In other words: for the API user changes are persisted
> after the call, he doesn't have to care about this. Still
> the implementation temporarily modifies the transient space.
> And actually, i think that this it's not quite correct.
Node.lock() changes are persisted after the call and there is no need to
call Node.save(). Internally, the method implementation calls a
Node.save(). I think both are saying the same idea.
--
Paco Avila <pa...@git.es>