Best Practices - Async Updates

  • Thread starter Thread starter James Cadd
  • Start date Start date
J

James Cadd

Please forgive the restatement of my post from a few days
ago, but I hope this question is more clear. I'm working
with a C# Windows Forms app.

What is the best practice for handling the changes made
by a user that occur after an asynchronous update has
been initiated, but before the update has completed? The
TaskVision sample application simply discards any data
returned by the data access web service if the user has
made any updates while the asynchronous update was
running. I'd like to merge this data back into the
client application, even if the user has made changes.
Which is a better way to do things?

Thanks in advance.
 
I think the best way is to prevent such situation from happening.

Otherwise you can rely on your common sense, which might be completely
wrong. ;-)

Really, in business application some transactions (or updates) are critical
and some are not. In your situation you allow two different updaters to
start with same data and now it is not clear who was first in the line. Can
you imagine ticket booth using this approach? Seat number 9 is available -
who takes it? Me! Clerk presses button and says "Sorry, seat number 9 sold
already - no more available". How would you react?

In your case if update was already initiated - another guy can't use this
data. You should lock all the rest of them out. If User was first - update
should not be initiated - data must be locked with user.

Samples are sometimes illustrating bad practices. Be careful with them.

To be serious, have a look at business requirements. Is that crucial or not?
And check what exactly you would like to merge? Two customers on same seat
or what?

HTH
Alex
 
Thank you for the insight Alex. The comments were very
helpful. Also, I found a good reference in the MS Data
Patterns book.
 
Back
Top