Slashdot Mirror

← Back to Stories (view on slashdot.org)

Data Locking In a Web Application?

Posted by timothy on 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."

46 of 283 comments (clear)

  1. Duct Tape by Anonymous Coward · · Score: 5, Funny

    Lots and lots of Duct Tape.

  2. Same as bugzilla? by Derek+Pomery · · Score: 5, Informative

    Same as bugzilla does. Just use a timestamp or counter on the records so you can tell when an edit occurred while you were editing
    Then you can review the edit.
    If you want, you can use XHR (maybe with a slow load response for performance depending on the number of users) to notify that an edit happened.

    --
    -- perl -e'print pack"H*","6e656d6f406d38792e6f7267"' /. ate my old sig. Bastards.
    1. Re:Same as bugzilla? by Anonymous Coward · · Score: 4, Informative

      Exactly, this is how I have done it in every web application I have developed. If someone updates the data while someone else is editing then they will get a message saying someone did an edit. They then get a chance to review the new data and modify their edit if needed.

      NOTE: It is critical that the user not lose their edit. Save that data even if you don't actually do the update. There is nothing more annoying than spending 15 minutes carefully putting in a bunch of data just to have it lost due to someone else editing the same record. Let the user review what happened and then modify (or not) their own data they were putting in.

    2. Re:Same as bugzilla? by dindi · · Score: 2, Informative

      On top of this you could actually send AJAX requests while editing to see if someone is requesting the data. Carefully, considering performance.

      An other option is to check-out, check-in with a session. In this case of course you need to make sure if a checked-out file's session is still alive.

    3. Re:Same as bugzilla? by Zarf · · Score: 4, Informative

      For the record this is called: http://en.wikipedia.org/wiki/Optimistic_locking

      --
      [signature]
    4. Re:Same as bugzilla? by Dexx · · 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.

      --
      Feel the fear and do it anyway.
    5. Re:Same as bugzilla? by nahdude812 · · Score: 5, Informative

      When a client wanted to know while they were working on a record that someone else had it open (they truly wanted the record locked while one user had it up on the screen), we used a LOCKED_BY and LOCKED_UNTIL field on each relevant record. While editing, records are read-only if LOCKED_UNTIL is in the future and LOCKED_BY is not the current user.

      On the edit page, an AJAX call is made on a 10 second interval which updates LOCKED_UNTIL to be +30 seconds (this way even if there are network issues of some sort, three consecutive status updates need to fail in a row). If the browser is closed or the computer blue screens, etc, after 30 seconds the record unlocks itself. When you save the record, LOCKED_BY is nulled, and LOCKED_UNTIL is set to the epoch.

      We also employed a version ID so that if all else fails and your client for some reason stops keeping the record locked (eg you suspend your laptop and come back to it later), when you submit your edits; if anyone else had made edits while your client was unable to keep the record locked, you're still given an indication that another user updated the record. The interval update checks the version ID too (a single SQL statement with PostgreSQL's excellent UPDATE RETURNING syntax) and warns the client if somehow someone else updated the version without this client having been able to maintain the lock - as soon as the next update interval succeeds the user gets notice.

      The ajax call was basically something like:
      UPDATE tbl_something
      SET locked_by = (current_user), locked_until = (time+30)
      WHERE record_id = (record_id)
      AND locked_by = (current_user)
      RETURNING
      locked_by, version_id

      Double check that locked_by is still the current user and version_id is still the known version of this record.

      --
      Slay a dragon... over lunch!
    6. Re:Same as bugzilla? by KillerBob · · Score: 2, 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.

      --
      If you believe everything you read, you'd better not read. - Japanese proverb
    7. Re:Same as bugzilla? by TheUnknownCoder · · Score: 2, Insightful

      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).

      --
      Uncopyrightable: The longest word you can write without repeating a letter.
    8. Re:Same as bugzilla? by TooMuchToDo · · Score: 2, Interesting

      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.

      I think Google Docs shows an excellent way of handling this. It uses AJAX to tell everyone on that page, spreadsheet, etc. who else is viewing/collaborating on it, and changes are reflected in real time. You don't have to go so far as to reflect changes in real-time, but just seeing who else is working on the doc would be helpful so you could IM them to collaborate and prevent collisions.

    9. Re:Same as bugzilla? by SoopahMan · · Score: 2, Informative

      This is a very good solution but it can still paralyze you if someone:
      * Opens an important record
      * Gets distracted
      * Leaves for vacation for 2 weeks

      Now their PC is locked with the page open and constantly polling, the record is locked forever, and people are angry. This can be solved with a message like
      "This record is locked. _Take Control of this record_" - Clicking it would up-end the equasion - in order to keep control the other user has to click a "I'm still editing" link within a minute. This would solve not only the vacation disaster, but the lunch annoyance.

      Depending on your resources and how large a "Record" is, you may consider getting more granular as well. You could lock by field, or form section, to capture use cases where for example "I'll type up the client notes, you update their contact info to fix any errors you find, and we'll call them about this as soon as possible."

    10. Re:Same as bugzilla? by kelnos · · Score: 2

      I've finally come to the opinion that locking is unnecessarily expensive, and doesn't tend to enhance collision handling capabilities beyond a simple concurrency timestamp check.

      I guess that's fine, depending on the users' needs. If "typical" edits require spending 20 minutes fiddling around with a web form before the user clicks the save button, I bet they're gonna be pretty pissed when they get a rejection message and their 20 minutes of work gets thrown away.

      With this in mind, if you're going to use your optimistic locking approach, you'd need to add more code that, instead of rejecting conflicting changes outright, presents the user with options, possibly listing the conflicting changes.

      Personally I'd find the auto-expiring lock option to be the best (the user will know going into it that someone else is editing), though hitting the DB to update the timestamp every 10 seconds doesn't scale to a large number of users. But there are other options, like ones some wiki software uses, where you get a longer locking period (on the order of several minutes), and you have to manually refresh the lock before it expires. Or you can possibly refresh the lock automatically, by checking to see if the user isn't idle.

      The unspoken question is, why not design a user workflow that avoids synchronization issues...?

      Yeah, that would be ideal, but may not be practical. The article poster says they're migrating a native app to a web app, so changing the users' workflow may not be an option.

      --
      Xfce: Lighter than some, heavier than others. Just right.
  3. This book: by walmass · · Score: 2, Informative

    on Google Books. You are welcome

  4. Re:The euphemism treadmill by Anonymous Coward · · Score: 4, Funny

    So that's what the song "Tainted Love" is really about! Who knew.

  5. The way this is generally handled... by Omnifarious · · Score: 4, Informative

    You make sure that edits are handled in a form on a web page with a submit button. The user gets to fiddle all the bits they want on the web page, then they hit the submit button. At that point the web app goes and locks the stuff it needs to do to update the database to reflect the user's changes. It then applies those changes, then commits them, thereby releasing all the locks.

    If two users might potentially be editing the same records, keep an SHA-256 hash of the original data around as a hidden form field. Then when the update proceeds, check the data to make sure the SHA-256 hash matches the data you fetched when you generated the form page (helpfully put into a hidden form field). If the hash doesn't match, tell the person who did the submit that some fields may have changed and somehow present them with what those changes might be.

    --
    Need a Python, C++, Unix, Linux develop
    1. Re:The way this is generally handled... by palegray.net · · Score: 5, Interesting

      My company has an internal app that approaches locking in a different manner. When you start updating a record, it uses an AJAX routine to set a lock on the record being updated. As long as you're still on that page, you "have the lock" and other users are notified of this if they attempt to edit the record. Once your changes are submitted, the lock is released automatically. It's possible to "steal" a lock in our model; this may not work for everyone. If you didn't want to allow this, you could incorporate a timeout for locks, whereby the original user would be notified that the lock had expired due to inactivity.

      --
      512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
    2. Re:The way this is generally handled... by omkhar · · Score: 2, Informative

      Storing the hash of the original data client side is bad from a security perspective. A malicious user could manipulate the hash as they sought fit. I'd keep the hash in a server side session specific variable. I realize the damage that could be done seems small, but I wouldn't trust *anything* - especially a critical part of your locking mechanism - to a variable that could be manipulated client side.

    3. Re:The way this is generally handled... by nanospook · · Score: 2, Insightful

      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.

      --
      Have you fscked your local propeller head today?
    4. Re:The way this is generally handled... by spiffmastercow · · Score: 2, Interesting

      How do you make sure the lock gets released when the page closes? I once investigated this, but determined that I would have to either a.) set a timeout on the lock and have the page update the lock every x seconds, or b.) use the page close event and hope that the user's browser doesn't close unexpectedly.

  6. Hibernate In Action (even if not using Java) by Zarf · · Score: 2, Interesting

    is a great book about this. Even if you don't use Hibernate or Java. If you hate Java just take the parts of the book dealing with Java and burn them. The rest of the book has awesome discussion of database design for the web... and those parts are worth the purchase price by themselves.

    "Hibernate in Action" covers "Optimistic Locking" which is a simple technique. Just put a versionNumber column in every table and never let anyone insert any version number less than the one in the database... http://en.wikipedia.org/wiki/Optimistic_locking ... if you have another scheme... even if it is smarter and better than this in every conceivable way DO NOT DO IT without FIRST getting Optimistic Locking working.

    --
    [signature]
  7. Optimistic concurrency by Shimmer · · Score: 5, Informative

    Slashdot is hardly the right venue to get a good answer to this question (how the hell did it end up in the Hardware category?), but I've dealt with this a zillion times, so I'll give a pointer to what is very likely the correct answer: optimistic locking.

    Hard locks are probably not what you want in a stateless web app. (E.g. What happens if someone locks a record and then is hit by a bus?) Instead, here's how it works:

    1. User X fetches version 1 of Record A.
    2. User Y fetches version 1 of Record A.
    3. User X modifies her copy of Record A and attempts to save the change.
    4. System checks whether incoming version (1) matches database version (1). It does, so the save proceeds and the version number on the record is updated to 2.
    5. User Y modifies his copy of Record A and attempts to save the change.
    6. System checks whether incoming version (1) matches database version (2). It does not, so User Y is notified that he cannot save his changes.
    7. User Y fetches version 2 of Record A and tries again.

    This is also known in the vernacular as "second save loses". It may sound too harsh, but it is much better than "first save loses and user isn't notified", which is what you get if you have no currency checking at all. And it's also much more web friendly that your old desktop app (which uses an approach that is technically called "pessimistic locking").

    --
    The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
    1. Re:Optimistic concurrency by gr7 · · Score: 4, Informative

      What shimmer says is exactly what you should do with 2 possible additions. Often people leave themselves in a web page for an hour and then start to make edits. So when the user makes the first edit, use ajax to see if there was already an edit done in the meantime so they know before they make lots of changes.

      Also you should consider using sequences instead of checking if the data changed. Both are good ideas in certain situations. For example with a table that is only edited once every few months, I use a sequence on the whole table. For a table that is changed 100 times per day by 3 different users, either do row based sequences or check to see if the 'from' part of the changes match the database.

    2. Re:Optimistic concurrency by Anonymous Coward · · 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.

    3. Re:Optimistic concurrency by hibiki_r · · Score: 4, 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.

    4. Re:Optimistic concurrency by ArcadeNut · · Score: 3, Funny

      Slashdot is hardly the right venue to get a good answer to this question (how the hell did it end up in the Hardware category?)

      Ok, so if Slashdot isn't the right venue to get an answer, should he ignore your answer?

      --
      Visit the Arcade Restoration Workshop @ http://www.arcaderestoration.com
    5. Re:Optimistic concurrency by MagicM · · Score: 2, Informative

      There is one gap in this. If steps 3 and 5 happen at the same time, then steps 4 and 6 happen at the same time, and both User X and User Y could pass the "System checks whether incoming version matches database version" check. Some locking is still required, otherwise it will look to both Users as if they "won".

    6. Re:Optimistic concurrency by argodk · · Score: 4, Informative

      Absolutely correct, but that just means that there has to be server-side locks for the commitment phase (4-6), it doesn't impact the client-side. This has an implication for performance of the commitment phase, but luckily, database vendors have been struggling with efficient implementation of commit for years, so using the transaction features of whatever database is used for storage should resolve most of those problems (i.e. check and update the version number in the database in a single transaction).

    7. Re:Optimistic concurrency by cerberusss · · Score: 5, Funny

      Hard locks are probably not what you want in a stateless web app. (E.g. What happens if someone locks a record and then is hit by a bus?)

      There's a Firefox extension for that.

      In our company, users' pulses are tethered to the USB bus. The Firefox extension can then use this information. People spend hours in our time accounting system, which has a pessimistic locking scheme. The Firefox extension sends an 'unlock' when the user's pulse stops for whatever reason. We've had buses driving users over, we've had rabid squirrels, a janitor going postal, exploding Sony laptops and a manager doing the 'Godfather-baseball-bat-routine' on an unsuspecting employee. Our time accounting system runs great, we've never had a stray lock.

      --
      8 of 13 people found this answer helpful. Did you?
  8. Confluence by goofy183 · · Score: 4, Informative

    Look at Confluence by Atlassian. When you edit a page they track the edit action. When another user goes to edit the page they are warned that "John Doe is currently editing this page, last edit at date/time". They also do polling via AJAX so if you're working on a page and another user starts actually editing it you see a message on the page "Jane Doe started editing this page". They also save page drafts scoped to the user to help people resolve edit conflicts. It seems to balance things well with not explicitly forcing locks but actively letting users know when they are heading for a conflict.

  9. CouchDB by deweller · · Score: 4, Informative

    Check out CouchDB. It is built around the concepts of distributed (and even offline) databases and handles conflict resolution. It employs optimistic locking.

  10. Use Optimistic Locking by linuxhansl · · Score: 4, Informative
    Don't take out a database lock (also referred to as pessimistic lock sometimes). Web transactions tend to be long lived and there's typically no easy way to know when the user just abandoned the edit (and hence you would not really know when it save to release the lock, unless it is by timeout or explicit release by the user).

    Instead do optimistic locking... Assume there are no conflicting edits (or that they are at least rare). Then version each row (with a monotonically increasing number for example). At the beginning of the transaction also retrieve the version, and upon save verify that the version did not change - if it has changed there was a conflicting edit in the meanwhile and the current save should be prevented (you could then get fancy and retrieve the current version of the row from the database and show it to the user, etc).

    One can actually show that if the rate of collisions is low optimistic locking even performs better, whereas in scenarios where the contention is high (a significant fraction of transaction result in a conflict) pessimistic database locks performs better.

  11. Re:use a hash/timestamp by larry+bagina · · Score: 2, Funny

    You could use an incrementing hash. Then you'd both be happy.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  12. Re:heh by IntlHarvester · · Score: 3, 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.

    --
    Business. Numbers. Money. People. Computer World.
  13. help the users by giving them info but not limits by roman_mir · · Score: 3, Funny

    I just made a console a month ago that handled this problem as follows:

    Records that need to be processed are in 'pending' (unconfirmed actually) status, once any user clicks to select the record, it is timestamped and the user is 'locking' it. Actually the user is assigned to it and all other users see that this record is 'locked' by the first user who selected it.

    However, now anyone can open the details of the record and do the following: they will see a button 'Take the lock away from $user$', so they can take the lock away! But there is history of who took whose lock, so the problem will be solved outside of the applicaction if they take each other locks away.

    If the user locked a record he has a choice of 'save', 'save and release lock', 'release lock' buttons on the record details.

    The users are allowed taking the lock away from each other so the lock resolution is pushed into the real world and out of the app.

    --
    You can't handle the truth.
  14. The way I do it by corychristison · · Score: 2, Informative

    Although I don't know what your implementation, or even what server-side language or database you use... I'll comment.

    - For the sake of simplicity, add 2 columns to the table you want to be able to lock. Call them `lk` (lock) and `lkts` (lock timestamp).
    - When a user is currently editing the row/document/whatever it is, have an icon of a lock or something to display in the list if someone is currently editing it.
    - When generating the list of 'documents'(/whatever it is), check `lkts` and compare it to the current time. If it is stale (5 mins old), clear it and allow people to edit it. Always allow users to view the data.
    - When a user clicks on the 'Edit' button, change the `lk` column to 1 and `lkts` to the current timestamp (UNIX_TIMESTAMP under sane DB's)
    - Use RPC or XML-RPC to save the document periodically (every 60 seconds or so). Every save, update the `lkts` with a fresh timestamp.
    - When the user clicks "Save and Exit" or "Save and Continue", have it submit the form the old fashioned way, save the data, and set `lk` and `lkts` to 0.
    - Use Javascript to detect how long of a period of time passes for of no-activity. If it goes on past, say, 10 minutes, submit the form (thereby clearing `lk` and `lkts` and allowing other users in to edit)

    This is bottom-of-the-barrel designed for simplicity. No security or anything in mind, but simply something that will work even after a browser crash or someone leaves the computer with a 'document' open and walks away.

    Disclaimer: Just worked 14 hours. Very tired, don't want to go into any more detail. If this makes absolutely no sense to anybody, please discard this message.

  15. The Only Choice is... by FlyingGuy · · Score: 4, Informative

    Optimistic Concurrency

    Both the curse and the blessing of web applications. Most of the work is offloaded to the browser, thus not bogging down the database servers with keeping a ton of row level locks in memory, or even worse, page level locks.

    For the programmers POV you use some back end language, php, java, ruby, python, it matters not, write a program, it launchs, connects to a database, ( no matter how much middle-ware you slap in ) sends it a query, gets the data, returns it for presentation, consideration and subsequent modification ( or not! ) by the user and then the program ends. You are no longer connected to the database, heck your browser is no longer connected to the server!

    Some have mentioned AJAX <sigh...> AJAX is nothing but bundling together a few different bits of tech to do ONE thing, make a call to the server without refreshing the page. No matter how you slice it and dice it, thats all it does, it makes a call through the web server, to launch a program written in one of the afore mentioned languages and it follows the same set of steps, through either the post method or the get method and nothing has changed!

    So you need a scheme to know if you can write to a record without overwriting someone else changes.

    The only real choice is to use a timestamp value, all databases support them, usually down to the millisecond of accuracy. It is a simple process which you can make more complicated as you desire. As many have mentioned, you read the record making sure you get the timestamp of the last update. That timestamp gets sent to the browser along with the data. When the user clicks save the stored procedure that does the actual update then compares the timestamp you are sending with the one on the current record as in "select for update ...." and if the one you are sending along does not match the one on the current record, then your update loses and the stored procedure reports that back and then you deal with the user feedback in any way you see fit. Typically this is done by sending back the record in is new state and telling the user, "sorry, but you have to star over.".

    Now having said that there is nothing to say that you cannot be imaginative with a bit of javascript or something like that, or even with the php array_diff() function or an equivalent in some other language then insert some fields above or below the the data that was previously changed to at least have the conflicting data shown in both forms eg: what it is NOW and what they wanted it to BE.

    --
    Hey KID! Yeah you, get the fuck off my lawn!
  16. Handled this on a web interface by JumpDrive · · Score: 2, Informative

    We ran into the same problem.
    What we finally did is lock the editing page, so that if someone else had it opened you were not allowed to update it until they removed the lock on that page.
    Or the user could over ride the page lock if they felt pretty sure that the other user was not using it for editing ( Maybe they just had it open on their desktop).
    In a table we put the page, user identification, and timestamp when the lock was created.
    So whenever the page was opened, it checked the table to see if it was locked. If it was locked, then it displayed header showing who had it locked and how long they have had it.
    We generally only have 3 to 4 users that may open a page for editing and they soon learn that if you are going to edit something after it has been sitting for some time to update the page.
    We should probably update this with ajax so that at least the header of the page tells the user someone else has taken the lock.
    But currently happens though is that the page won't update if it doesn't have a lock and the user has to go back if and start over if someone stole the lock. So far I haven't heard of it happening, because they usually open or update right before they start editing so they know they have the lock.
    But handling it in this manner has greatly reduced our problems.


    Yeah, it's amazing how if you think it could happen it will. And most of our problems, I think, were caused by users opening the same page on multiple computers and then instead of closing the page, they were updating the page with the old information.

  17. Way more informtion by mindstrm · · 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?

  18. Do as ticketmaster does... by Lord+Byron+II · · Score: 3, Interesting

    When you are ordering tickets through TicketMaster.com, they hold the seat assignment for you for 10 minutes. If you don't complete the transaction within that time frame, the tickets become public again.

    In your database setting, the user Alice wants to edit the customer Carol's record. The application gives Alice a lock on Carol's record for five minutes. If user Bob tries to edit Carol's record within the five minute window, he gets a message telling him to wait for 3:42 while Alice finishes her edit. When Alice is finished, the lock is released and if she doesn't finish in five minutes, the lock is released anyway and her edits are lost.

    You could also add the ability for the user to set the lock time, within a reasonable window, say 5-15 minutes. Also, consider adding the ability for the user to renew the lock.

    BTW - Paradox is still around? I haven't used it since 1993 or so. Wow.

  19. This is user requirements, not implementation by viking80 · · Score: 4, 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.

    --
    don't cut it off www.mgmbill.org
  20. This sounds a lot like a RDBMS... by drfreak · · Score: 3, Informative

    Locking is a solved problem in most Database Management Systems. I think you are worried about the wrong layer of your application. Web and Application code is most often agnostic to how records are retrieved, updated, and locked for concurrency. For reference, look up the ACID properties of a typical RDBMS.

  21. Locking sucks; use versioning. by DamnStupidElf · · Score: 2, Insightful

    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...

  22. This is how I do it by frambris · · Score: 2, Interesting

    I have a separate locks-table with lock_id, id of the other record and timestamp. When a user brings up the record it is read only. He have to click Edit to begin editing and thus requiring a lock. This is where the lock table is checked. If there are no locks a lock entry is inserted and its lock_id is propagated to the edit form. Upon saving one checks that it is the same lock id, saves and removes lock. If a user tries to edit a locked record one can give him the option of either wait, or override if the users credentials allow it. He then get a new lock id. The other user either get an error message when saving stating that another one override his edit or some AJAX controller periodically checks the lock and takes action if it disappears. If the user just closes the edit form, forgets about it one can expire the lock by deleting old locks.

  23. Re:If you don't already know, get off the project. by timmarhy · · Score: 3, Insightful

    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.

    --
    If you mod me down, I will become more powerful than you can imagine....
  24. give users an edit-lock by molecular · · Score: 2, Interesting

    This is how we did it in an in-house AJAX app for a big corporation.

    There would be a temp-table for every editable data-table in the db, that has the same structure plus a ID_User field. When a users starts editing a data-set, the data is copied into that temp-table. Other users trying to edit that data will get a view-only version of the page and info on who is editing the data. On "submit" the data is copied back to the "real" table, the lock thereby released.

    Should a user decide to abandon his session, crash his browser or anything like that, he will have his unsaved edits back on next login. He will even be redirected to the edit page automatically after login, if there are pending edits.

    A user can "steal" his own lock (actually session, that is) when he tries to log in with a fresh session (e.g. from another workstation at a colleague's). The old session will bail out automatically saying "session hijacked" (on any next ajax action) and the fresh session will get loaded with the old one's data.

    Other users can only steal locks after a timeout (to avoid problems with people going on vacation with locked data on them)

    ----

    This eactually worked pretty well from a user's perspective, because as opposed to with optimistic locking there would never be a situation where a user would have done some edits in vain or have extra work rechecking it.

    From a developer's perspective it was a pain in the ass (maintain 2 almost identical tables, maintain checkout/checkin-code everytime).

    From support's point of view, it wasn't too bad. Seldomly people would call and demand release of a lock because someone just went to have coffee and he had to edit the data real quick or managment would kill him on the spot because the data would be frozen in like 7 minutes to generate reports.

  25. Here's what to do. by Animats · · Score: 2, Insightful

    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.