none
Is it safe to do BeginSaveChanges(null, null) with a TableServiceContext?

    Question

  • I'm looking for a safe way to perform a sort of async "fire and forget" table storage call. I thought doing this would do just that:
    BeginSaveChanges(null, null);

    But, I noticed that when doing this multiples times in a row the very last one sometimes doesn't seem to execute. My guess is that the 'instance' of the datacontext died too fast for that insert to happen? Is that most likely the cause?

    When I switch it to SaveChanges all the inserts are successful.

    Thursday, August 26, 2010 8:56 PM

Answers

  • Hello, you may encounter 2 problems if you don't invoke the End method:

    1. You don't have a chance to handle exceptions. The operation fails silently, and it may be difficult to find the root cause of your problem later on.

    2. Under certain scenarios (especially if unmanaged resources are used), this will lead to memory leak. I can't say for sure if HttpWebRequest (which is used by TableServiceContext under the hook) uses unmanaged resources or not.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Yi-Lun Luo Thursday, September 02, 2010 9:06 AM
    Friday, August 27, 2010 2:33 AM

All replies

  • If you don't provide a callback where do you call EndSaveChanges(). Note that you don't get the benefit of retries unless you use BeginSaveChangesWithRetries() from the TableServiceContext class.
    Thursday, August 26, 2010 9:11 PM
    Answerer
  • Sure, I understand. The question was is passing NULL for a AsyncCallback ok to do? Some folks seem to think that you must always supply one. Is it really required? If my DataContext is disposed before the BeginSaveChanges has completed does it not perform the query?

    Or should I be using a different approach for a 'Fire and Forget' method? Perhaps I should wrap making an instance of my datacontext and query execution in a Task?

    Thursday, August 26, 2010 9:14 PM
  • Jeffrey Richter's (awesome) book CLR via C# advises: Always call the EndXxx method and call it only once because of potential resource leakages. I suspect it will be a lot easier to put the callback in and do a correct implementation of BeginXxx/EndXxx than any of the alternatives.
    Thursday, August 26, 2010 9:24 PM
    Answerer
  • We'll usually make fire-and-forget calls like so:

     

    SomeContext ctx = GetServiceContext();

    ctx.AddObject(_tableName, new SomeContext(userId, token));

    ctx.BeginSaveChanges(ar => ctx.EndSaveChanges(ar),

    null);

    If there is a reason to do it differently I too would be interested in learning more.

    Friday, August 27, 2010 12:10 AM
  • Hello, you may encounter 2 problems if you don't invoke the End method:

    1. You don't have a chance to handle exceptions. The operation fails silently, and it may be difficult to find the root cause of your problem later on.

    2. Under certain scenarios (especially if unmanaged resources are used), this will lead to memory leak. I can't say for sure if HttpWebRequest (which is used by TableServiceContext under the hook) uses unmanaged resources or not.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Yi-Lun Luo Thursday, September 02, 2010 9:06 AM
    Friday, August 27, 2010 2:33 AM