Skip to content
GitLab
Menu
Projects
Groups
Snippets
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
Menu
Open sidebar
typo3
qfq
Commits
14364fb6
Commit
14364fb6
authored
Dec 20, 2019
by
Carsten Rose
Browse files
Revert "Add some statement to Locking."
This reverts commit
e2bedb70
parent
921d3c5b
Pipeline
#3090
passed with stages
in 2 minutes and 11 seconds
Changes
1
Pipelines
1
Hide whitespace changes
Inline
Side-by-side
Documentation-develop/PROTOCOL.md
View file @
14364fb6
...
...
@@ -484,9 +484,6 @@ Server Response
### Record lock
Request, extend or release a lock for a record, identified by the SIP. The SIP contain a SIP_FORM and a SIP_R (record id).
See
`Documentation-develop/diagram`
for a state diagram.
To detect record change at time of 'record lock' or 'record save', a MD5 hash is provided from the server
and needs to pass back to dirty.php as well.
...
...
@@ -500,7 +497,6 @@ URL Parameters
:
`s=<SIP>`
(form, r)
:
`action=lock`
,
`action=extend`
,
`action=release>`
:
`recordHashMd5=<value of hidden form element 'recordHashMd5'>`
:
`tabUniqId=<unique id>`
Server Response
: The response contains an [Lock Response].
...
...
@@ -513,7 +509,7 @@ JSON Response from the server (extended [Minimal Response]) containing:
: {
: "status": "success"|"error"|"conflict"|"conflict_allow_force",
: "message": "
<message>
"e5
: }
:
}
`status`
indicates how the request has been fulfilled by the server.
On
`"success"`
, the Client display nothing to the user.
...
...
@@ -524,18 +520,11 @@ On `"conflict_allow_force"` the Client opens the alert non-modal (default).
### tabUniqId
*
Client: Every browser tab get's a
`tabUniqId`
(timestamp) as soon as the first time a lock is requested (acquire).
This
`tabUniqId`
remains, until the tab is close. It is saved in window.name.
*
Server: On lock request, the
`tabUniqId`
is saved in dirty record.
*
The
`tabUniqId`
helps to implement 'optimistic locking': if there is no argument against 'grant lock' - grant it.
Example: In browser tab 'A' a lock is requested. For unknown reason, there is a stale lock for the
user session and the given tab id: grant the log.
*
Unexpected async behaviour in client: On page reload (F5), the 'lock release' might come after 'lock acquire'.
The form goes in 'read only' mode - an additional page reload (F5) solves the situation - but this is boring.
Every tab get's a uniq id (timestamp) on page load: window.name.
This 'tabUniqId' is saved in dirty record on lock acquire.
On page reload, when the 'release' comes after 'acquire' (unwished async behaviour), the locking is skipped (if same user
session) - on reload there is no variable 'tabUniqId'. On real lock acquire, the tab ID is compared and will be denied
if not matching. The 'tabUniqId' might not work in IE - doesn't matter: it's a seldom special situation.
### Drag And Drop (sort)
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment