[MAGNOLIA-3905] Remove usage of ExclusiveWrite Created: 08/Dec/11 Updated: 14/Feb/14 Resolved: 17/Dec/12 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core |
| Affects Version/s: | None |
| Fix Version/s: | 5.0 |
| Type: | Improvement | Priority: | Critical |
| Reporter: | Fabrizio Giustina | Assignee: | Daniel Lipp |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Template: |
|
||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||
| Date of First Response: | |||||||||||||
| Description |
|
Performances of concurrent editing in Magnolia is highly affected of the global sinchronization on ExclusiveWrite, expecially due to the usage in SaveHandlerImpl. ExclusiveWrite was more a quick and dirty hack than a solution to concurrency implemented years ago. The main reason why it's bad is that is global: no matter which node you are saving or which repository you are working on, you will hold a lock which will block any other dialog from saving. That means that also saving a document to the dms or anything else into the data module is actually locking the whole system for editing. A second reason why it's bad: it has totally no effect on clustered instances, since it's local to a single Magnolia instance. IF the problem it's trying to fix is concrete, synchronization should be done on a repository level, not at instance level. A good approach would be using jcr locks on nodes (locking works also with a clustered repository). Since Magnolia actually uses a "soft locking" approach everywhere, by allowing concurrent editing assuming that concurrent save operation on the same node would be really limited, my suggestion is to simply get rid of the synchronization block in SaveHandlerImpl, without introducing addictional checks at the moment. |
| Comments |
| Comment by Jan Haderka [ 07/Feb/12 ] |
Magnolia doesn't support clustering of the author environment and the locks as you pointed out are applied to editing, hence only valid on authoring environment. So there's no issue with cluster. However you are right that choosing the different solution would allow clustering of the author instances as well.
The problem solved by exclusive write is exactly what you describe - it ensures all writes are serialized hence the one who saves the content last is the one whose changes are being saved. The problems prevented by exclusive write are those that arise when for example one editor deletes a paragraph while the other is saving his changes to the very same paragraphs.
JCR locks were not an option years ago since releasing them forcibly by other user then creator was problematic. This might have indeed gone much better now with JR actively supporting clustering. However using JCR locks still doesn't solve one problem - attempt to save same content by multiple users - In this case you end up with an exception telling user that node is locked. The dialogs and saving of content must be completely revisited if we were to use JCR locks to make sure that no control does ever partial save op but saves all its changes in one go. This applies also to special controls that might be saving content over more then one workspace. Also explanation of the problem would have to be given to user so ensure they understand somebody else just saved the very same piece of content and attempting to save it again should work, but content might not be what they expected anymore (comparison in that case would be nice). Alternatively, Dialog handler (and all other code that saves the content) need to catch the exception and keep retrying until it succeeds or until limit of retries or timeout is reach in which case it would present the problem to user. As you can see, solution to this is more complex then simple replacing of exclusive write with JCR locks. As such I would suggest to develop a prototype on a branch, review the solution and once agreed apply it on trunk. |
| Comment by Jan Haderka [ 14/Mar/12 ] |
|
This is a major change and as such should be done as part of the major release, not in maintenance. |