Commit 14364fb6 authored by Carsten  Rose's avatar 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
......@@ -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
* 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:
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)
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment