Ticket #9558 (closed PLIP: wontfix)
Locking improvements - Better collaborative edition
Reported by: | dukebody | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | Future |
Component: | General | Version: | |
Keywords: | Cc: |
Description
http://plone.org/products/plone/roadmap/189
Plone 3.0 has been released with a basic locking system. This proposal gives some ideas of the improvements to this package and continues the work that has been done for PLIP #145.
Proposed by
Jean-François Roche
Proposal type
Architecture
Assigned to release
- Improve locking configurability
State
being-discussed
Definitions
Pessimistic locking: Pessimistic locking is an approach where an entity is locked in the database ... A lock either limits or prevents other users from working with the entity in the database... A read lock indicates that the holder of the lock does not want the entity to change while he hold the lock, allowing others to read the entity but not update or delete it. ( http://www.agiledata.org/essays/concurrencyControl.html)
Optimistic locking: The idea is that you accept the fact that collisions occur infrequently, and instead of trying to prevent them you simply choose to detect them and then resolve the collision when it does occur. ( http://www.agiledata.org/essays/concurrencyControl.html)
Motivation
Increase collaborative edition of objects while preventing users from overwriting other users' work. This is a big argument make plone enter in big organizations.
- 2 locking policy
o Optimistic locking (see definition bellow) - not implemented o Pessimistic locking (see definition bellow) - implemented
Manager should be able to select the policy which fits the most to its needs...
- 3 locking types
There is three main types of locking that could be useful (see details in the definition).
o Exclusive locks o Shared locks o Freeze
Current implementation has just one type of locking (Exclusive locks).
Each of these types should be declined for different purpose to give the ability to other developers to define their custom locks for their application (e.g CMFEditions) Assumptions
We can depend on zope.locking.
Proposal
- Shared locks
This feature would give the ability to the user who locked an object to share the lock with other users. Only subset of the persons having edit modification on this object should be added for sharing. This implies that we will reintroduce simultaneous edition of an object and will get again write-write conflicts. Optimistic locking will have to be introduced for this to work (see bellow)
- Freeze
A document which is frozen can only be read and not modified any more. This should be available for the owner and the manager. Frozen object could be frozen forever or have a frozen duration.
- Optimistic locking (aka Optimistic Concurrency Control - OCC)
Previous release of the locking package disabled write-write conflicts by removing the possibility to another user to edit a document while another is editing it (exclusive locks). This is called pessimistic locking.
With the introduction of shared locks, different users will be able again able to edit simultaneously an object. Optimistic locking let different users to edit document concurrently but check data integrity on save. As we have now ajax and kss we should be able to determine earlier if the object has been changed since we began to edit it. Once the change has been detected a conflict resolution algorithm/method should be called.
Different algorithm/methods exists. A comparison between theses algorithms/methods has to be done and discussed.
Optimistic locking increase a lot concurrent access to objects this is really important in highly concurrent environments where locking a complete object for edition isn't an option.
- Improve Exclusive locks
Current implementation of the exclusive lock allow a user to keep the lock indefinitely unless someone steal it.
*
o First of allow stealing a lock should depend on a permission different than "Modify portal content".
*
o There should be some configuration to set a timeout after what the lock is automatically removed.
*
o Once the lock has been stolen the user who had the lock should be notified (using KSS). A periodic refresh should be implemented to check if the lock has been stolen
- We shouldn't use Webdav locks as a base for locking
Current implementation relies on webdav locks. We should use a much more generalized lock system and not rely on the Zope 2 webdav lock any more. Webdav should rely on the locking package, not the opposite.
- Fields Locking
For the moment you can just lock a full object. With KSS you can now edit just a field with inline editing, it's a pitty to have the whole object locked while editing just the description for example. Fine-granular locking will lower the probability that two parts of an object get edited at the same time.
- Better Plone locking awareness
Once a object is locked operation like : workflow changes, cut, remove, metadata edition, setters ... shouldn't be allowed anymore
- Avoid hooks in Archetypes base_edit
We have a very nice z3 event system machinery base_edit should fire a IObjectBeforeModificationEvent and we should subscribe to this event instead of write locking specific code in Archetypes. ....
- Lock icons should be seen in the folder contents view
This issue wasn't solved in 3.0 , it needs to be solved for 3.5
- Stealing a lock shouldn't reload the page
We have kss now... better use it more.
Implementation
zope.locking has already the base implementation for lock tokens. It gives the base infrastructure answer for shared lock, freeze lock and timeout locks. The code also enable multiple locks per object. This code is well documented and will be maintained so I see no reason why we shouldn't use this.
Optimistic locking will requires more developements than the other features. Plone 3.5 is more infrastructure focused so i think it is the time to think about it.
Deliverables
Risks
++ Optimistic Locking
- Minimize User Lockout - Better concurrency
- easy to use
-- Optimistic Locking
- Allows overwriting if the user don't care
- User need to handle the merge in case of conflict, this might be difficult to understand if the ui isn't good enough
++ Pessimistic Locking
- Simple to develop
- Prevent overwriting
-- Pessimistic Locking
- Low concurrency
- Lock more than it should lock (e.g user editing only the description and the full object is edited)
- More risk to walk away and let the lock intact
Choice depends on the needs of the user <b>not</b> on the application.
- AJAX is good, but we also need to ensure this stuff can work with
AJAX/JS turned off.
Progress log
11 october 2007 -- Nothing written yet. Need to get some opinion first
Participants
- Jean-François Roche
whishing to see more people in this list ...
PLEASE READ THIS AND RE-OPEN VALID PLIPS!
As we launch the new PLIP process we'd like to see which PLIPs:
If this PLIP should still be considered for future releases of Plone please do re-open this ticket and assign an appropriate milestone. If it should be considered for the next release of Plone, use the 4.2 milestone. Also be sure to update the PLIP description, requester, owner, etc. and include a comment detailing recent progress and new plans. We will use all these details in the new continuous PLIP process.