2

I am developing a web site of artists profiles and a desktop software to manage its database content. There are many operators that will receive in their in-boxes the same amount of pending records to be revised for approval and publish. The problem is when two or more operators try to edit the same record. It the database server (remote mysql) will raise an lock error or simply will maintain only the data of the operator that saves it for the last.

What would be the best approach (simpler and more efficient way) to check if any one is already editing the record before grant access to this record to another user, or if the owner of the record is, himself, updating his record again in the website?

The software is still at the lab. But when I delivery it to client I know it will be a problem.

I could create a table to flag each record as "in edit" or "idle", so I don't need to alter the structure of the tables (because people are already using them on the site). But I need to be sure that there is a more elegant/faster way to do it.

wallyk
  • 56,922
  • 16
  • 83
  • 148
NaN
  • 8,596
  • 20
  • 79
  • 153

1 Answers1

5

There are many system-level approaches you could use to handle the problem. Locking a record for exclusive editing is only one, traditionally chosen by older systems.

A more modern methodology is to allow both edits to proceed without locking—termed optimistic concurrency control. If there is an overlapping edit, see if it can be resolved automatically—many simultaneous edits are, in fact, not contentious, especially if they edit unrelated parts of the record.

In the case there is a conflict, it is important that the first edit not be simply lost: the first editor was already signaled of a successful transaction. The onus is to indicate to the second editor that their edit conflicts with an earlier one. Usually the best course is to show him his proposed change as well as the other recent change and let them select what to do: abandon their change, override the previous change (maybe with an indication to the first editor), or manually merge the changes.

This may not be a big deal. The description of your system suggests users would not be closely synchronized to an edit-worthy event. The random time at which each edit occurs suggests an edit conflicts would be rare. In such a case, maybe your idle/editing indication is more than sufficient.

wallyk
  • 56,922
  • 16
  • 83
  • 148
  • don't you think that this new table would increase at least by 50% the information traffic? that's what I'm afraid of... – NaN Jul 15 '12 at 23:14
  • 2
    @EASI: Offhand, I don't see how any of these approaches would affect traffic. Even if it were an issue, preventing data loss, performing reliably, and doing what users expect is far more important than a system or network being busy. The systems are there to serve humans--not the other way around. – wallyk Jul 16 '12 at 03:21