Data Locking In a Web Application? 283
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."
Re:The way this is generally handled... (Score:2, Insightful)
Re:Optimistic concurrency (Score:3, Insightful)
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.
Re:Optimistic concurrency (Score:5, Insightful)
+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)
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.
Re:Same as bugzilla? (Score:5, Insightful)
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.
Way more informtion (Score:3, Insightful)
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?
This is user requirements, not implementation (Score:5, Insightful)
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.
Locking sucks; use versioning. (Score:3, Insightful)
Re:If you don't already know, get off the project. (Score:4, Insightful)
Re:Same as bugzilla? (Score:1, Insightful)
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
Re:Way more informtion (Score:1, Insightful)
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?"
Re:Same as bugzilla? (Score:3, Insightful)
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.
Re:Same as bugzilla? (Score:2, Insightful)
Here's what to do. (Score:3, Insightful)
OK. Here's what to do.