7

Situation: multiple front-ends (e.g. Silverlight, ASP) sharing a single back-end server (WCF RIA or other web service).

I am looking for a standard to prevent multiple people from editing the same form. I understand that this is not an easy topic, but requirements are requirements.

Previously I used the DB last modified date against the submitted data and give a warning or error if the data was modified since it was loaded. The initial system simply overrode the data without any warning. The problem is that I have a new requirement to prevent both these situations. There will be many UIs, so a locking system might be a challenge, and there is obviously no guarantee that the client will not close the window/browser in the middle of an edit.

I would appreciate any help.

Peet Brits
  • 2,911
  • 1
  • 31
  • 47
  • I'm not quite sure I follow. Are you looking for a pessimistic system of locks which prevents user from editing something it believes is already in process of being edited? OR are you looking for something optimistic which allows multiple editing but the rejects submissions when data has changed? – AnthonyWJones Sep 17 '10 at 12:29
  • The pessimistic locking scenario is too limiting, so I'm scratching the idea. I don't want users to edit for 30 minutes just to reject their changes when someone else beat them to submitting a change. – Peet Brits Sep 17 '10 at 14:01
  • But the optimistic merging scenario requires a lot of extra work from my side, since I will need a tool that allows the client to merge public properties on objects, probably in a grid-like fashion. – Peet Brits Sep 17 '10 at 14:05
  • Related: http://stackoverflow.com/questions/129329/optimistic-vs-pessimistic-locking – Peet Brits Nov 18 '10 at 09:33

1 Answers1

10

If I'm correct, it seems what you are talking about is a form of check-out/edit/check-in style workflow. You want when one user is editing a record, no other users can even begin to edit the same record.

This is a form of pessimistic concurrency. Many web and data access frameworks have support for (the related) optimistic concurrency - that is, they will tell you that someone else already changed the record when you tried to save. Optimistic has no notion of locking, really - it makes sure that no other user saved between the time you fetched and the time you save.

What you want is not an easy requirement over the web, since the server really has no way to enforce the check-in when a user aborts an edit (say, by closing the browser). I'm not aware of any frameworks that handle this in general.

Basically what you need is to hold checkout information on the server. A user process when editing would need to request a checkout, and the server would grant/deny this based on what they are checking out. The server would also have to hold the information that the resource is checked out. When a user saves the server releases the lock and allows a new checkout when requested. The problem comes when a user aborts the edit - if it's through the UI, no problem... just tell the server to release the lock.

But if it is through closing the browser, powering off the machine, etc then you have an orphaned lock. Most people solve this one of two ways: 1. A timeout. The lock will eventually be released. The upside here is that it is fairly easy and reliable. The downsides are that the record is locked for a while where it's not really in edit. And, you must make your timeout long enough that if the user takes a really, really long time to save they don't get an error because the lock timed out (and they have to start over). 2. A heartbeat. The user has a periodic ping back to the server to say "yep, still editing". This is basically the timeout option from #1, but with a really short timeout that can be refreshed on demand. The upside is that you can make it arbitrarily short. The downside is increased complexity and network usage.

Checkin/checkout tokens are really not that hard to implement if you already have a transacted persistant store (like a DB): the hard part is integrating it into your user experience.

Philip Rieck
  • 32,368
  • 11
  • 87
  • 99
  • Headache! Why do I need more than one user anyway? :-/ – Peet Brits Sep 17 '10 at 14:12
  • But yes, it is between pessimistic and optimistic concurrency. Although I prefer the optimistic approach, it could potentially require a lot of work (see my comment in the main post). Your pessimistic heartbeat option sounds the safest, but I have to decide if the (ugly) trade-offs are worth it. – Peet Brits Sep 17 '10 at 14:16
  • +1 each, good Q&A. Basicly confirmed what I was thinking... didn't think of the heart-beat though. – John Hoven Sep 24 '10 at 16:05