lockInfo incorrect after saving a document

[idzelis@…]

[jira2trac import : issue created on October 26, 2005 4:24:42 PM CEST ​http://issues.cocoondev.org/browse/DSY-201 ]

I modified the layout.xsl to display a warning in addition to the live/retired warnings. The warning looks at the lockInfo for the $document and if it has a lock, it displays a msg saying the document is currently being edited.

I've noticed that after saving a document, the lockInfo still reports that there is a lock being held, even though it is possible to edit the document without getting hitting the "document already locked" error. If you edit and then hit cancel, the lockInfo is corrected.

I'm thinking there may be a caching issue with the lockInfo element.

[paul]

[jira2trac import : comment created by bruno on October 27, 2005 3:17:57 AM CEST]

This might be related to DSY-141

If a user edits a document and then presses save or cancel, the lock info should be cleared.

If a user edits a document and then simply closes the window/tab, the lock info will not be cleared. However, next time someone tries to take a lock the system will see the old lock is expired and remove it. The issue DSY-141 above mentions the need for a background thread that clears up these locks regularly.

Since locks are related to a user, and not to a particular editing session, a user can simply take a new lock if there is still an old lock for that same user, the lock will simply be updated.

Please confirm if the problem you are seeing is only related to the lack of this assynchronous lock cleanup, or still something else.

[paul]

[jira2trac import : comment created by idzelis on October 27, 2005 10:49:08 AM CEST]

This is not the same problem at DSY-141.

Starting condition: There is no lock on the document at all.

Now you edit the document, modify it, and save it.
The <d:lockinfo> elements appear in the document with stale lock information. (hasLock=true)

I've verified that going to daisy's jmx port and clearing the document cache will cause the <d:lockinfo> element to accurately reflect the state of the lock for the document.

[paul]

[jira2trac import : comment created by bruno on October 28, 2005 4:30:00 AM CEST]

You're quite right, I was testing this wrongly (getting the document using /repository/document/x, which always retrieves a fresh copy).

This is fixed in SVN revision 2387.

The LOCK_CHANGE events, which invalidate the cache, were only sent when a lock was created, not when it was removed. Now it sends the event for all lock changes.