Question

I have a number of methods that ultimately call my this._context.SubmitChanges method. Because all of my methods operate asynchronously, it’s possible in my app (albiet unlikely) that multiple methods might try and submit before another submitchanges is complete.

Now, I know I can use the IsSubmitting method to make sure I don’t try and call one submit while another is occurring. I’m just wondering which direction to go from here. I’m not sure it’s really necessary to to set up a queue, since multiple entities looking to submit changes will all get rolled up under a .SubmitChanges call.

I have a callback function on each of the submitchanges that I make. One option would be to throw a flag into my app that, in the callback, checks to see if the flag was set during the interim. If flag was set, it fires off another round. Seems hackish though. Is there a better way?

Thanks.

[Edit]

I don’t have as much EF fu as I’d want, but I think I’m keeping them separate, as outlined in the code below (my VM constructor)… when I’m looking to submit changes, it’s on each of these independent entityLists…

Here is an example call to submitchanges (where each call is using a different entitylist)

this._keywordSource.Add(new Keyword() { keyword = searchText });
if (this._context.Keywords.HasChanges && !this._context.IsSubmitting)
{
    this._context.SubmitChanges(KeywordsAddedCompleted, null);
}

Here is code from my viewmodel constructor:

this._gnipRuleSource = new EntityList<GnipRule>(this._context.GnipRules);
this._keywordSource = new EntityList<Keyword>(this._context.Keywords);
this._cachedSource = new EntityList<CachedKeywordResult>(this._context.CachedKeywordResults);
this._feedSourceSource = new EntityList<FeedSource>(this._context.FeedSources);

this._gnipRuleLoader = new DomainCollectionViewLoader<GnipRule>(LoadGnipRules, LoadGnipRulesCompleted);
this._keywordLoader = new DomainCollectionViewLoader<Keyword>(LoadKeywords, LoadKeywordsCompleted);
this._cachedLoader = new DomainCollectionViewLoader<CachedKeywordResult>(LoadCachedKeywords, LoadCachedKeywordsCompleted);
this._feedSourceLoader = new DomainCollectionViewLoader<FeedSource>(LoadFeedSources, LoadFeedSourcesCompleted);

this._gnipRuleView = new DomainCollectionView<GnipRule>(this._gnipRuleLoader, this._gnipRuleSource);
this._keywordView = new DomainCollectionView<Keyword>(this._keywordLoader, this._keywordSource);
this._cachedView = new DomainCollectionView<CachedKeywordResult>(this._cachedLoader, this._cachedSource);
this._feedSourceView = new DomainCollectionView<FeedSource>(this._feedSourceLoader, this._feedSourceSource);

Answer 1

I’m at the same place and I’m considering implementing a queue simply because I can then be sure that my operations are being committed reliably and in order. I’ve done a little bit of research and haven’t yet found a nice pattern to deal with this situation.

Your callback pattern does seem like an easy workaround, though. Hacky in it’s lack of structure, but if you ensure all submits go through a single piece of code then it should be easy enough to implement and maintain. It would almost certainly be quicker to implement that a queueing pattern.

Checking IsSubmitting and avoiding the SubmitChanges, to let the uncommitted change be rolled into the next submit that’s called (as you describe) works fine. Unfortunately it will eventually lead to some uncommitted changes (the last change in a user’s session wasn’t persisted because IsSubmitting was true at that time). It would be ‘bad luck’ when that happens especially as it’s unlikely that multiple submits will happen quickly, but it would be extremely annoying for users and testers who wouldn’t be able to replicate the bug.