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>