Distributed Document Locking Web Style

Notes and Domino applications often revolve around documents and approvals. When editing a document the application must ensure that nobody else can edit it. In Lotus Notes applications we have the Document locking functions which can even do a distributed locking. Looks good works well, if it wouldn't be for the last sentence in the developer help: Locks are not supported in Web applications. So you need to roll your own. Distributed operation can be tricky. The solution is to use an XPage (or servlet for older versions of Domino) on each server that runs a locking service. This service figures out what's the master lock server and tries to use it. If succesful it issues a lock, on failure to reach it it provides a provisional lock. The master server registers which server has asked for a lock status and notifies them when a lock is removed or renewed. Lock information is locally cached to minimize user delays. The flow would look like this:

There are a number of considerations when designing the detailed functionality:

• Should the document be locked only by the service (for web documents) or also for opening the documents from a Notes client
• Should the locking service use the master server to lock (yes if you answered the previous question with yes), optional - you could get away with code without Domino classes
• How to execute the locks: do a Ajax call before opening? Run the check in the QueryOpen? Check on save that you had a valid lock?
• Should a lock expire automatically (so no unlock function is needed) but the clients need to renew their locks periodically. How long would a lock live (5 minutes in a typical webDAV server)?
• Should a lock be persistent (the opposite of the expiring locks) and survive a server reboot?
• Would single sign-on be required (LTPA)?
• What would a syntax look like both for requests and responses?

This is what I came up with:

http://one.ofmy.servers.com/lockmaster.nsf/service.xsp?action=lock&db=databasereplicaid&doc=documentuniqueid
http://one.ofmy.servers.com/lockmaster.nsf/service.xsp?action=status&db=databasereplicaid&doc=documentuniqueid
http://one.ofmy.servers.com/lockmaster.nsf/service.xsp?action=unlock&id=locktokenid
http://one.ofmy.servers.com/lockmaster.nsf/service.xsp?action=relock&id=locktokenid

Since a user "talks" to their own server the lockmaster has access to session.username. So a relock or unlock request can be verified against the user who made the original reqest and ignore/reject invalid username/token combinations. The response from the lockmaster would be in JSON and rather lean:

{ "status" : "ok|fail",
   "db":"databasereplicaid",
   "doc":"documentuniqueid",
    "owner":"Full name of the Owner"
    [, "id":"tokenid"]
    [, "expiry": 600]
    [, "msg":"Eventual explanation of the failure"]
}

The response slightly varies depending on the type of action performed and by whom. Using this approach you should have a fairly robust browser based locking mechanism.