Prevention of duplication of editing / Locking database records during editing - single server server

Question

Situation: several interfaces (for example, Silverlight, ASP) sharing one internal server (WCF RIA or another web service).

I am looking for a standard that allows several people to edit the same form. I understand that this is not an easy topic, but requirements are requirements.

I used to use the last modified DB date in relation to the data presented and give a warning or error if the data has been changed since the download. The original system simply overloads the data without warning. The problem is that I have a new requirement to prevent both of these situations. There will be many user interfaces, so a locking system can be a problem, and obviously there is no guarantee that the client will not close the window / browser in the middle of editing.

I would be grateful for any help.

Answer 1

If I'm right, it seems that you are saying this is a check-out / edit / check-in workflow form. You want one user to edit a post, other users cannot even edit the same post.

This is a form of pessimism concurrency. Many websites and data access systems support optimistic (related) concurrency - that is, they will tell you that someone else already changed the record when you tried to save. Optimistic does not have the concept of locking, in fact - it ensures that no other user is saved between the selected time and the save time.

What you want is not an easy requirement on the Internet, since the server really does not have the ability to force registration when the user interrupts editing (for example, closing the browser). I do not know of any frameworks that handle this as a whole.

Basically, you need to keep the verification information on the server. When editing, the user process must request verification, and the server will provide / reject it based on what they verify. The server will also need to store information that the resource has been verified. When the user saves the server, he releases the lock and allows him to request a new check. The problem arises when the user interrupts editing - if he is using the user interface, no problem ... just inform the server about the release of the lock.

But if it is closing the browser, turning off the computer, etc., then you have an orphaned lock. Most people solve this one of two ways: 1. Timeout. The lock will eventually be released. The surface here is that it is fairly simple and reliable. The disadvantage is that the recording is blocked for a while when it is not in edit mode. And you have to make your timeout long enough so that if the user really needs a very long time to save, they don't get an error because the blocking time (and they should start). 2. Heartbeat. The user has a periodic response to the server to say "yep, still editing." This is basically a timeout option from # 1, but with a very short timeout that can be updated on demand. On the plus side, you can make it arbitrarily short. The disadvantage is increased complexity and network usage.

Verification / verification signs are really not that difficult to implement if you already have transactional persistent storage (for example, a database): the difficult part integrates it into your user interface.