Concurrency Management is needed when two or more users edit the same record at the same time. Think of a contact, which gets opened for editing at the same time by two users. After one minute, the first user finished his changes and presses the save button while the second one is still working on the contact data. Now the second user is working on an old version of the contact. At the moment he presses the save button, we have a typical concurrency problem.
What can be done in a typical concurrency situation?
The most easy way is, just to ignore the conflict and save all data-sets ‘as the come’ into the database. This is called The last one wins or just no concurrency management. Needless to say, that in this case, the work of the fist editor is destroyed. But what’s more harmful is, that the first editor is not even notified or encouraged to review the data again. This is how the current eGroupWare 1.x works.
A better way of managing this situation, is to reject the save request from the second user with the notice that a concurrency problem has occurred. Than this user can fetch the updated contact an merge his changes manually. This procedure could be annoying for the second user, especially if there is no real conflict, cause the fist user modified other fields than the second user.
So what Tine 2.0 can do, is to detect in what fields the changes where made. This way it’s possible that Tine 2.0 merges the changes silently, when the user didn’t change the same field(s). We call it a resolvable concurrency conflict. At the moment it’s not clear if we should configure Tine 2.0 to act this way, or if it just should reject changes w.o. merging. The problem is, that the second user might be confused, that the contact in the database is not exactly the one he saved.
I made a little screencast to demonstrate the implementation in addressbook of Tine 2.0. This is my first screencast, so please be patient with me 
Wouldn’t it be nice to show the user the differences between his changes and the changes made by another user? Let se user deceide if he would like to merge his changes, forget the other changes made before or cancel his changes…. What about record locking?
Happy New Year!
Yes, thats the idea in a second step for the frontend. The screencast only shows the current backend state.
When the backend tells the frontend/client that there is a concurrency problem, the frontend could decide how to handle this conflict. So a merging-helper would be part of the client.
Record locking might be possible if only human clients are involved, but also in this case it could be a problem: What happens if a user don’t close the dialog, or if the client dies?
But the real problem why locking is not an option, are the sync users, e.g. mobile devices. For this kind of clients we need a smart concurrency management anyway.
Fajna stronka, bede tu wpadal czesciej, pozdro