Forgot your password?
typodupeerror
Databases Programming Hardware

Data Locking In a Web Application? 283

Posted by timothy
from the get-offa-my-cloud dept.
An anonymous reader writes "We recently developed a multi-user application and deployed it to our users. This is a web-based application that used to be a Windows application which was written in Delphi using Paradox databases for the client database. In the Windows application, we used the ability in Paradox to lock records which would prevent users from editing the same data. However, in the web application we did not add in a locking facility for the data due to its disconnected nature (at least that's how I was shot down). Now our users are asking to have the locking back, as they are stepping on each others' edits from time to time. I have been assigned to look at best practices for web application locking of data, and figured I would post the question here to see what others have done or to get some pointers to locations for best practices on doing locking with in a web application. I have an idea of how to do this, but don't want to taint the responses so I'll leave it off for the time being."
This discussion has been archived. No new comments can be posted.

Data Locking In a Web Application?

Comments Filter:
  • by nanospook (521118) on Thursday September 24, 2009 @11:17PM (#29536399)
    Some interesting ideas here.. Especially the AJAX idea.. However, consider this. Any scheme that involves telling the user "after the fact" that the record has changed is "wasting" the user's/companies time and money, resulting in rework. If your scheme tells you ahead of time that so and so has the lock and you can't, then you save the user's efforts. Of course, I'm speaking generically in that some data entry systems might be ok with multiple edits of the same records.
  • by Anonymous Coward on Thursday September 24, 2009 @11:42PM (#29536537)

    Slashdot is hardly the right venue to get a good answer to this question

    Actually slashdot is really good at this kind of stuff, there was a few dozen relevant, on-topic, well-written replies soon after the question was posted.

    On the other hand, political discussions ... embarrassing.

  • by hibiki_r (649814) on Thursday September 24, 2009 @11:47PM (#29536563)

    +5 Is not enough for the value of the parent post. Optimistic Locking is the right answer in 99% of the cases. The issue then becomes how you want to deal with re-submitted of changes. If the entities to be saved are small and very atomic, asking the user to retype, making sure their changes are still sensible on the modified record makes sense. If your records are very large and/or very complex, then you might consider using some business knowledge to see if changes to the record can be grouped logically, and maybe even committed individually: If someone changed data for X shipment of a purchase order, while someone else changed Y, then the changes don't really have to conflict.

    But whatever you do, build it around optimistic locking: Don't try to lock a record because somebody just has it open somewhere on a remote location. That path leads to madness.

  • Re:heh (Score:4, Insightful)

    by IntlHarvester (11985) * on Thursday September 24, 2009 @11:50PM (#29536581) Journal

    Actually, I don't blame them. The first instinct of people coming from a client-server background is to introduce to some form of record locking. Since this isn't "in the box" with web app frameworks, it makes sense to push back on the feature until you have user feedback or other analysis that it's actually required. Otherwise you are spending valuable time coding/debugging a feature that will rarely ever be used.

  • by Dexx (34621) on Friday September 25, 2009 @12:01AM (#29536627) Homepage

    To ensure the edit isn't lost, we handle this by kicking the user back to the form with a message. You could go one step further and get the modified record from the DB, then highlight the field in question and give the user the option to keep/override. You could make it more intelligent by detecting the collision, analysing the difference, then committing if no fields conflict. Depends on the business logic, I guess.

  • by mindstrm (20013) on Friday September 25, 2009 @12:25AM (#29536709)

    I think we'd need way more information to come up wiht a good solution - this is an overall application architecture problem, not just a locking problem.

    What are the use cases? what kind of app is it? what is it that you are trying to lock, exactly?

  • by viking80 (697716) on Friday September 25, 2009 @12:36AM (#29536777) Journal

    This is more a question of requirements than implementation. If your users want wikipedia style optimistic locking, just do that. If your users want hard locking with a timeout, do that. Just like your online bank does.

    If users ask for hard locks without timeout, ask them what their real requirements are.

  • by DamnStupidElf (649844) <Fingolfin@linuxmail.org> on Friday September 25, 2009 @01:25AM (#29536953)
    Wikipedia gets by without locking because it keeps multiple versions. If you really want to do locking, just throw a column in your database called "locked_by" and lock a record with "update foo set locked_by=CURRENT_USER where foo.id=WHATEVER and locked_by is null" and make all your updates conditional like "update foo set bar=baz, ..., locked_by=null where foo.id=WHATEVER and (locked_by is null or locked_by = CURRENT_USER)". Databases have atomic transactions for a reason...
  • by timmarhy (659436) on Friday September 25, 2009 @04:02AM (#29537259)
    i don't argee. while he shouldn't be leading the project, he can still work on it. did you know everything about every application you've ever worked on operated??? this is how real world experience is gained, you don't start out the expert.
  • by Anonymous Coward on Friday September 25, 2009 @04:26AM (#29537335)

    I absolutely HATE this method, because 90% of the time you are given: "Their edited field" and "Your edited field" - both of which are completely useless for comparing changes. Please, if you do this, make sure to show changes, not end results. (This can be as simple as including the "original" alongside

  • by Anonymous Coward on Friday September 25, 2009 @07:20AM (#29537899)

    If you have more than 10 minutes professional DB experience, you would know the poster has given ample information already. In fact, all he needed to say was "multi-user web app record locking, how?"

  • by KillerBob (217953) on Friday September 25, 2009 @09:05AM (#29538565)

    Mod parent up.

    That's basically what I was going to suggest, and I think it's more in line with what the clients of the OP are asking for... in Paradox, when a record was locked it was tagged read-only until it was unlocked (or the lock expired). This way, when you're using a multi-user database access program, one user can open/edit a record, and other users can access the information within, but nobody else can modify it. So if you implement it the way parent is saying, you'll end up with a system that's much more in line with the behaviour that the client had with their Paradox database, and will likely give better functionality.

    The way that other people are suggesting, honestly, would just annoy me. I'd be *really* pissed if I opened a document, spent half an hour working on it, then committed my changes only to find out that somebody else had been spending time working on it as well. That adds up to a lot of wasted time. If, however, I were given an indication that somebody else was editing it, I could work on a different record without wasting my time.

  • by TheUnknownCoder (895032) on Friday September 25, 2009 @10:32AM (#29539397)
    Beautifully simple! If I may add: try to keep all this functionality inside your Data Access Layer. That will really make things simpler in the presentation layer (your web pages).
  • Here's what to do. (Score:3, Insightful)

    by Animats (122034) on Friday September 25, 2009 @12:44PM (#29540937) Homepage

    OK. Here's what to do.

    1. Demonstrate how Wikipedia locks. Edit something in the Wikipedia sandbox from two adjacent computers, demonstrate what an "edit conflict" looks like, and show how you resolve it.
    2. Demonstrate how a hard-lock version control system, like Microsoft Visual SourceSafe, locks. Show what happens when you try to check out something on one machine that's already locked on another machine. Point out what happens if someone leaves something checked out.
    3. Get your management to decide which approach they want.
    4. Implement.

The flow chart is a most thoroughly oversold piece of program documentation. -- Frederick Brooks, "The Mythical Man Month"

Working...