I've got a listbox on a Silverlight Page with 128 items. If a user "selects all", all rows are selected and I iterate the selected rows collection and either call an insert/delete WCF method which calls a stored proc in a SQL Server database for each row.
What appears to be happening, on occasion, is the Silverlight client is finishing the "for loop", calling the async method for each row, but the call to refresh the two listboxes is beating the asynch methods for insert/delete on the WCF host (localhost
at the moment). I am left with either "phantom rows", rows that were that were processed by the WCF host but the query to refresh fired before WCF completed the async calls -or- items that were not processed by the WCF call, which is frightening to
say the least. The pass/fail for this exercise is about 50/50 - sometimes all the rows are processed and there are no items left behind, other times items are either left behind, but a refresh shows they were processed but the SL client asked for the data
too quickly or items are left because they weren't processed by WCF async calls.
Not sure if my answer will suffice but in my experience with Silverlight and Async calls this comes down to the design of your application.
First off, why don't you take a look at batch processing in SQL, this way you make way fewer async calls to the server and SQL can handle inserts/deletes in batch format.
Secondly, regardless of weather or not you choose to send multiple async updates to the server you should always notify the end user that something is happening in the background. I've found a subtle notification sliding in on the right or toast messages
goes a long way, maybe even disabling the control until you know for sure all processing has completed..?
Do you make use of the Completed eventHandlers for Async calls?
serviceInstance.YourMethodCompleted += new EventHandler<YourMethodCompleted>(serviceInstance_YourMethodCompleted );
I ususally wait for this event to fire before removing notifications. If you choose to go with the async call for every insert/delete, maybe you could use a count variable to track how many items should be deleted/inserted and with every
Completed event that fires, subtract one until you get to zero and notify the user/rebind the list and/or free up the interface... I would seriously advise against this though as you can not account for async calls
that never send a reply due to timeouts etc...
This might not be a best practice, but I usually rebind controls like lists after I've updated their content.