The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Record locking

Hi, I have a question about locking. This doesn't have to be only about record locking, but anyway.

Let's say i'm writing a web accessable CMS. I am struggling with some ideas.

I could, on the moment when a user opens an article for editing, flag the article as being 'in use'. so far so good.

but when do I remove the flag? when the user saves the article? but what if the user doesn't feel like typing anymore and decides to close his browser and go to bed?

a time-out mechanism comes to mind, but how long does it take to write an article? 10 minutes too short, 30 minutes too long..

Maybe I am overcomplicating, I'd like to hear your thoughts on this subject.
Guyon Morée Send private email
Tuesday, September 07, 2004
If you are working on a web-enabled project avoid record locking like the plague.

You're better off using "collision detection". This can be done in a number of ways. The basic idea is that when a user tries to save their changes a check is made to see if anyone else has changed the record during the time the user was doing his/her work.
Freddie boy
Tuesday, September 07, 2004
Here's another vote on avoiding web-based record locking.

The web is especially conceived as a stateless protocol, answer one request and forget about it.  Of course you have some server-side mechanics to simulate state (such as cookies), but these are usually so long-lived (at least in database termsà you do NOT want to base your record strategy on this.

Much better, as Guyon suggested, to perform a collision check when the user submits the modified data and give him some options:

- overwrite the data with your own changed
- discard your changes
- merge your changes with the others (more complex)
Sam Send private email
Tuesday, September 07, 2004
Oops, I meant "as Freddy suggested" of course.

Sam Send private email
Tuesday, September 07, 2004
Thanks for the ellaboration, Sam. I was going to add something about HTML being stateless and the options available if a collision occurs, but got interrupted by a meeting..

One confounding factor with a web-based system is the "back" button on the browser. Nothing is easier than clicking on an "Edit record" button and then hitting "back" on your browser rather than hitting a "Cancel" button. The server doesn't know you have hit the "back" button. Bang goes a record-locking scheme!  Sure you could try to work around this problem, but why bother? The "back" button is a great feature of browsers so we should work with it rather than against it. Collision detection does just that.
Freddie boy
Tuesday, September 07, 2004
Indeed, I really really avoid the web-based locking scheme, even if the idea seems imprinted in some people's mind sometimes (mostly people who have only done one particular type of application, the 'monolithical UI and db at the same place, concurrency whats that?' kind of application).

For the OP, the only thing you really need to do is get a "last updated" timestamp somewhere in your database, allowing you to easily see if it has been changed by someone else.

In ASP.NET things have been complicated a bit though with teh advent of Postbacks, raising the question do you need to 'refresh' your record during a postback or not? You could of course ignore the database and go ViewState, but thats not really a valid solution for complex pages as well.

Sam Send private email
Tuesday, September 07, 2004
"Collision detection" is also named "optimistic locking". The other choice is "pessimistic locking".
Tuesday, September 07, 2004
You can use a "version" column to facilitate the "optimistic locking".  Say user opens a file with version 2.  Version 2 is saved in a hidden field somewhere on the page, or in your session, DB, etc.  When you go to save the file, you check if the version has been updated to 3 or above "while you were out" so to say.

If it has, then dis-allow the submition until user refreshes to the latest version of the record, and performs a manual merge -- that is the easiest way to go.

I hope that makes sense.

Greg Nudelman Send private email
Friday, September 10, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz