XRX/檔案鎖定
< XRX
您希望建立系統以避免多個使用者同時修改資料而導致覆蓋彼此修改的問題。
考慮以下場景：Bob 將資料載入到他 XForms 應用程式的配置檔案中，進行了部分修改，然後去吃午飯，並在午飯後才將資料儲存回伺服器。午飯時間，Alice 在她的 XForms 客戶端開啟相同的資料，做了一些修改並儲存。當 Bob 午飯回來後，他對相同的資料進行了儲存，從而覆蓋了 Alice 的所有更新。
這被稱為“丟失更新問題”，在多個使用者可能同時編輯相同資料的場景中很常見。
解決此問題有許多策略，每種策略都有一些設計限制。
通常，您會發現兩種獨立的鎖定策略，可以一起或獨立使用。
第一個策略是在將資料移至客戶端時對資料進行校驗和。儲存時，重新計算資料的校驗和，並確保資料沒有更改。您也可以將最後修改時間戳放入客戶端，並在檔案自使用者開始編輯後發生更改時提醒使用者。HTML 標頭內的 etag 元素通常用於儲存資料的 md5 校驗和。
第二個策略是在編輯資源時設定伺服器上的某些狀態，並在使用者未儲存的情況下提供合理的超時時間。此方法始終更復雜，因為您必須處理解鎖資源，這通常涉及用於檢視鎖定檔案的工具和報告。
此處介紹的策略是在使用編輯表單時鎖定檔案，並在執行儲存操作時解鎖檔案。
eXist 提供了一些簡單的函式來鎖定檔案。此鎖定可用於阻止第二位使用者開啟編輯會話。這種方法的缺點是，如果檔案被鎖定而使用者沒有進行儲存，則必須建立一個工具來允許手動解鎖記錄。
以下是一些您可以在 eXist 上使用的鎖定函式
util:exclusive-lock($a as node()*, $b as item()*) item()*
Puts an exclusive lock on the owner documents of all nodes in the first argument $a. Then evaluates the expressions
in the second argument $b and releases the acquired locks aftertheir completion.
util:shared-lock($a as node()*, $b as item()*) item()*
Puts a shared lock on the owner documents of all nodes in the first argument $a. Then evaluates the expressions
in the second argument $b and releases the acquired locks aftertheir completion.
xmldb:document-has-lock($a as xs:string, $b as xs:string) xs:string?
Returns the name of the user that holds a write lock on the resource specified in $b in the collection $a.
If no lock is in place, the empty sequence is returned. The collection can be passed as a simple collection path or an XMLDB URI.