[
https://issues.apache.org/jira/browse/JSPWIKI-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134347#comment-18134347
]
Arturo Bernal commented on JSPWIKI-107:
---------------------------------------
Checked in the current code (upstream master) and on a running instance (Tomcat
10.1).
The lock described in the report still exists. Edit.jsp takes the lock when the
editor is opened (PageManager.lockPage) and releases it when editing is
cancelled; otherwise it expires after the time of jspwiki.lockExpiryTime, 60
minutes by default. The scripts of the editor do not tell the server anything
when the tab is closed or the user goes back, so the lock stays until it
expires, which is the situation of the report.
What changed is the effect: the lock does not stop anybody. I opened the editor
of the same page from two separate sessions; the second one got the editor with
the message that the user has started to edit this page but has not yet saved,
followed by I won't stop you from editing this page anyway, BUT be aware that
the other person might be quite annoyed. So the cost of a stale lock today is a
warning.
The proposal of the description, a ping from the client or a release when the
page is left, is not implemented, and neither is the draft saving on the server
suggested in 2008; the editor does keep a draft in the local storage of the
browser. Limits: I tested with two anonymous sessions only, and I did not check
what happens to the lock when a page is saved. Leaving the issue open.
> Enhancement to page editing on the client's side to minimise the "do not
> edit" time
> -----------------------------------------------------------------------------------
>
> Key: JSPWIKI-107
> URL: https://issues.apache.org/jira/browse/JSPWIKI-107
> Project: JSPWiki
> Issue Type: Improvement
> Environment: n/a
> Reporter: Florian Holeczek
> Priority: Minor
> Fix For: STRIPES/JCR-3.1
>
>
> The status quo in page editing is as follows:
> Clicking on "edit" makes the Server mark a wiki page as "currently being
> edited" for a certain time. This timer may be stopped by:
> - X minutes without any action
> - a save or cancel request from the edit page
> - nothing more!
> Now, web surfers don't care about technological issues and are lazy, so in
> the majority of cases the user would simply close the edit page or use a go
> back function of his web browser, if he changed his mind and didn't want to
> edit the page anymore.
> The problem arising is that on the server side, the page is still marked as
> being edited for a potentially long time. In the meantime, other users can't
> really edit the page because they're being warned that someone else is
> editing it, although this may not be true anymore.
> This wouldn't be a big problem in a rarely visited wiki, but it's a really
> big problem in a frequented wiki. Additionally, it has been found that most
> of the page lockings occur due to spiders and spambots, not users as such.
> My proposal is something like:
> - making the client have to send a ping from time to time (so that if the
> page has been closed, the ping isn't sent anymore)
> - adding onExit, on... handlers signalling a cancel action to the server.
> Of course it doesn't help against wiki spam, but the "do not edit" time will
> be minimised. In a way, it's comparable to greylisting in the e-mail domain.
> You make the client tell repeatedly that its request is still valid. Fewest
> spiders or spambots will respond to that.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
