I've got a collection I show to users - a collection which supports updates and inserts.
Although unlikely, it is possible to have this collection open on two people's workstations at one time. I'm trying to think through a good concurrency handling techinque.
What I've come up with is applying a date/time stamp to the entire collection so that this date/time stamp is stored in a separate table. I grab that date/time value when I load up the collection and when I save the collection that value gets changed to the current date/time. If a person tries to save the table and that value doesn't match then changes were obviously made while they had the colletion open - they are informed and the collection would be re-opened with the lastest changes (thereby losing theirs).
I'm used to handling this on a per item basis - I've never done this for an entire collection.
The storing of a date/time stamp in a different table seems "clunky" to me.
thoughts?
I would lean toward having a stamp in each item in collection,
not collection itself. This way you can allow one user to edit item A
while another user can edit item B, and allow both changes to commit.
Sergey Barskiy
Principal Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Magenic ®
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: MadGerbil
[mailto:cslanet@lhotka.net]
Sent: Friday, August 22, 2008 1:35 PM
To: Sergey Barskiy
Subject: [CSLA .NET] Concurrency & Root Collection
I've got a collection I show to users - a collection which supports updates
and inserts.
Although unlikely, it is possible to have this collection open on two
people's workstations at one time. I'm trying to think through a good
concurrency handling techinque.
What I've come up with is applying a date/time stamp to the entire
collection so that this date/time stamp is stored in a separate table. I
grab that date/time value when I load up the collection and when I save the
collection that value gets changed to the current date/time. If a
person tries to save the table and that value doesn't match then changes were
obviously made while they had the colletion open - they are informed and the
collection would be re-opened with the lastest changes (thereby losing theirs).
I'm used to handling this on a per item basis - I've never done this for an
entire collection.
The storing of a date/time stamp in a different table seems
"clunky" to me.
thoughts?
Let's say the collection contains 10 items which are open on two users workstations. Let's also say that the users both edit the same 5 items. They both press "Save" and one user's items get saved while the other user is stuck with 5 items that could not save - or worse yet, one item that did save and 5 others that didn't.
How would you communicate what happened to the user who just lost his changes?
Firstly, I was never able to come up with an answer to that that
is satisfactory. I tend not to use concurrency in general because I think
it results in bad user perception of the application, usually worse than last
wins scenario. Just my opinion though.
I would probably raise a specific error in SP so that you can
listen to it in your UI. If you see that error inside Catch block (.BusinessException)
in your UI when Save is called, just show an appropriate message and allow the
user to reload the data and re-do the changes. There is not much else you
can do I think.
Sergey Barskiy
Principal Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Magenic ®
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: MadGerbil
[mailto:cslanet@lhotka.net]
Sent: Friday, August 22, 2008 2:00 PM
To: Sergey Barskiy
Subject: Re: [CSLA .NET] RE: Concurrency & Root Collection
Let's say the collection contains 10 items which are open on two users
workstations. Let's also say that the users both edit the same 5
items. They both press "Save" and one user's items get saved
while the other user is stuck with 5 items that could not save - or worse yet,
one item that did save and 5 others that didn't.
How would you communicate what happened to the user who just lost his
changes?
My take on that issue is if you want the system where concurrent
updates are “safe”, then your BO should track the fields that have
changed and only update/modify on DB end the fields that have been modified on
UI. That way you do not care if the value in consecutive update has been
modified, that was the intent.
You can handle deletes in the same manner. If user A
deletes the record that user B tries to update, then the update is treated as
an insert.
Nermin
From: Sergey Barskiy
[mailto:cslanet@lhotka.net]
Sent: Friday, August 22, 2008 1:07 PM
To: Nermin Dibek
Subject: RE: [CSLA .NET] RE: Concurrency & Root Collection
Firstly, I was never able to come up with an answer to that that
is satisfactory. I tend not to use concurrency in general because I think
it results in bad user perception of the application, usually worse than last
wins scenario. Just my opinion though.
I would probably raise a specific error in SP so that you can
listen to it in your UI. If you see that error inside Catch block
(.BusinessException) in your UI when Save is called, just show an appropriate
message and allow the user to reload the data and re-do the changes.
There is not much else you can do I think.
Sergey Barskiy
Principal Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Magenic ®
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: MadGerbil
[mailto:cslanet@lhotka.net]
Sent: Friday, August 22, 2008 2:00 PM
To: Sergey Barskiy
Subject: Re: [CSLA .NET] RE: Concurrency & Root Collection
Let's say the collection contains 10 items which are open on two users
workstations. Let's also say that the users both edit the same 5
items. They both press "Save" and one user's items get saved
while the other user is stuck with 5 items that could not save - or worse yet,
one item that did save and 5 others that didn't.
How would you communicate what happened to the user who just lost his
changes?
I think "last one wins" is a disaster, because the first user's changes are lost without notice.
Any concurrency solution (at least one that doesn't stop the user from even starting to make edits that can't be saved with locking mechanisms that are there own can of worms) is going to anger the "losing" user. So, you just have to decide who is going to lose. I think "first one wins" is best, because at least you can inform the loser that they're changes weren't saved.
We use "changed values concurrency" as our solution because it provides better concurrency than timestamps. So, users can edit the same object at the same time, and if they don't change the same field, both edits will go through. This is implemented by including the previous values of all changed fields in the WHERE clause sent to the database. If someone else changed one of the fields, then the WHERE clause won't match any records and you can detect the concurrency violation that way.
Concurrency control is hard, and what strikes me is that in your message you imply that the likelyhood of an issue occurring is small. If this is the case, is the work to implement a good concurrency solution going to provide sufficient RO? How about implementing an audit trail instead where you use triggers to track the insert, update and delete operations? Then if an issue ever does occur, and you get a support call, you can use the audit trail to explain what happened. Indeed if you provide a searchable frontend to the audit table(s) and educate your customers, then they can research the issues themselves.
Yes I have implemented this in 'real life' and it worked well. Just my 2cents :-)
Copyright (c) Marimer LLC