XRX Locking Grain Design

by Dan McCreary

XForms allows you to load an entire XML database into a client with a single statement. But this is not always a good design decision. Consider the concurrent user access requirements when you design the grain of your locks.

In the past, when we developed with POHF (Plain Old HTML Forms) each web form has a small set of key-value pairs. Developers loaded multiple transforms of the database through middle tier objects into the web form. They then updated the database by reversing these transformations. Developers tended to work at lower levels of the tree (the root being the top of our upside-down tree).

With XForms however, you can easily load an entire database into your client with a single statement. To do this you just add the following line to your XForms model.

<xf:instance src=”path-to-my-xml-database.xml”/>

But just because XForms enables the developer to easily do this does not always make it a good design decision. XForms give the developer great power, but this power needs to be used responsibly and you need to take your multi-user requirements into account when you do this.

Why? Consider the issues surrounding the locking of records to prevent multiple users from overwriting each other’s changes. Most databases provide record locking. With eXist this is just a simple XQuery statement (util:exclusive-lock) that the developer puts on the server when an update form is loaded.

What you need to consider is how to gracefully deal with multiple clients accessing the same data. Ideally the first user gets the data and sets the lock. The second user should be notified that the record is locked, when it was locked (and perhaps by who) and only allow them a read-only access. By the way, turning a form into a read-only form is just a single line of code in XForms also. See http://en.wikibooks.org/wiki/XForms/Read_Only. I have been tempted to put a nudge button on these forms to let the locker know that someone is waiting for them to close the form, but I have not got around to that yet.

I have also created many administrative XForms for giving non-techies the ability to change things like server configurations. They don't need to use an XML editor and I can set up complex business rules using bind statements that prevent accidental configuration errors. I wish Apache configuration files can with an XForms front-end! In this case I just lock the file on the server and load the entire configuration file into the XForms client. In this case, the locking grain is course.

You still may want to save prior versions of these configuration files and use XML diff tools (which are also bundled with eXist) to see who changed what and when. And you may want to allow users to revert to a prior version with a single click. But most of this work is just a few additional lines of XQuery on the server.

What you find is that all these lock/read/nudge operations can be done simply and elegantly with the combination of using XForms clients, XQuery on the server and REST interfaces.

What is needed now is a unified framework built around XRX to make all theselocking issue something that is can be addressed in a single XQuery module that can be loaded on the server.

Note that you don't need to lock records as they are being created but you may want to check for duplicate records as the users enter their data. This can easily be done in an as-you-type submission if you don't mind a little extra bandwidth.

So how have you dealt with locking in the past? Do you have any techniques that you have developed in the POHF/RDBMS era that we can use in the XRX era?

1 Comments

Mike Amundsen
2008-05-30 06:59:25
The best approach I know of for this is using ETags for any updates. Check out http://www.w3.org/1999/04/Editing/ for details. Basically, when you get the doc, you get a hash-key. When you send the updated doc, you send the same hash key. If the hashes match, the server knows no one else has updated the doc.