incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <janne.jalka...@ecyrd.com>
Subject Re: Versioning now available
Date Sat, 25 Jul 2009 15:22:52 GMT
>> * Could checkout() be made part of the page-locking process? Could  
>> the
>> act of placing a PageLock prompt a checkout() operation?
>
> req's reworking of pagelocks; embedded use does not require locking.  
> They are conceptually different also, since pagelock can last for a  
> long time.

Also, to continue in this vein, JCR also supports locking as a  
separate thing, and that's conceptually even more different than  
PageLocks. I haven't yet figured out a good use for the JCR locking in  
JSPWiki context. It has a couple of downsides:

* JCR locks expire randomly.  That is, most of the time they do not  
expire, but there is usually a cleanup process which randomly throws  
away old locks. JCR defines no way to configure this.
* JCR lock tokens require a lot of safekeeping; if you lose one, you  
can't unlock.
* JCR locks don't have the necessary metadata to replace PageLocks;  
those would need to be managed manually anyway.
* PageLocks can be broken trivially programmatically; JCR locks  
cannot, unless you have the token.

JCR locking is really meant to prevent concurrent modification by  
multiple accessors.  I think we might find them very useful when we  
enable clustering, but before then I'm not too sure what to use them  
for.

/Janne

Mime
View raw message