XRX/File Locking

Motivation edit

You want to put systems in place to avoid the problem of concurrent users writing over each other changes.

Consider the following scenario. Bob loads the data to a configuration file into his client XForms application, makes half of his changes and then goes out to lunch before he does a save back to the server. During lunch Alice opens the same data in her XForms client, makes some changes, and does a save. When Bob gets back from lunch he does a save on the same data and wipes out all of Alice's updates.

This is known as the "Lost Update Problem" and is common when you have many users that may be concurrently editing the same data.

Two Strategies for Managing Client Locks edit

There are many strategies to solve this problem, and each of them have some design limitations.

In general you will find two separate locking strategies which can be used together or independently:

The first strategy is to do checksums on the data when you move the data to the client. When you save, you recalculate the checksum on the data and make sure it has not changed. You can also put the last modified timestamp in the client and warn the user if the file has changed since they started editing it. The etag element within the HTML header is frequently used to hold an md5 checksum of the data.

The second strategy is to set some state on the server when a resource is edited and provide reasonable timeouts if the user does not do a save. This method is always more complex because you must deal with unlocking resources and this often involves tools and reports to view locked files.

The strategy presented here is to place a lock on the file when an Edit form is used and unlock the file when a save is performed.

eXist provides some simple functions to lock a file. This lock can be used to prevent the second user from opening up an edit session. The drawback to this approach is that if a file is locked and the user does not do a save, then a tool must be created to permit records to be manually unlocked.

eXist Locking Functions edit

Here are some of the locking functions you can use on 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.

References edit

Back: Login and Session Management • Next: Selection List Generator