none
Help with a multi-threaded app RRS feed

  • Question

  • I'd like some advice on a WPF/Linq To Sql application that I have built.

    I have read that the proper way to manage a DataContext is to create it, use it and get rid of it ASAP. But I don't understand how to do that when you have a UI that depends on an active DataContext. For example, my UI has a DataGrid (that makes heavy use DataTemplates to have one DataGrid indide of another) and few ComboBoxes and TextBoxes - all with Bindings to Linq To SQL objects. When I tried to close the DataContext, the UI has all sorts of problems.

    But the user needs to interact with the database and the work performed during intereaction is often performed asyncronously on worker threads. And since the DataContext won't allow calls to SubmitChanges from any thread other than the one that created it, it makes doing background work sort of tricky.

    What I have resorted to doing is working with a number of different DataContexts: one for the UI that basically lives for the length of the program, and others that come into and go out of existance on background threads to do the work of updating the DB.

    But I'm not altogether happy with this solution and continue to look for other (better) ways to do this. So, any help, advice, links would be appreciated.

    Thanks,

    Bill

    Tuesday, September 28, 2010 6:39 PM

Answers

  • Sorry for the late response. I had previously read that. The information as presented seems to not be completely correct, however. Specifically, I've not been able to access a DC on separate threads in all situations. For example, it doesn't seem possible to make changes on one thread and then call SubmitChanges on another.

    What I've ended up doing is having one global GUI DC where the user makes changes but SubmitChanges is never called. User changes are collected, and then applied to another DC (inside of a TransactionScope) on another thread where SubmitChanges is eventually called.

    GUI data refresh is accomplished by destroying the existing DC and making a new one.

    Thanks,

     


    -- Bill McCormick ACE-CO
    Wednesday, November 3, 2010 4:23 AM

All replies

  • Hi Bill,

    We are looking into your question and will respond as soon as possible.

    Thank you,

    Cathy Miller

    Microsoft Online Community Support

    Friday, October 1, 2010 4:58 PM
    Moderator
  • Bill,

    This might help you in deciding how to manage the DataContext lifetime.

    http://www.west-wind.com/weblog/posts/246222.aspx

    Regards,

    Jay [MSFT] 

     

     

    Saturday, October 2, 2010 12:03 AM
  • Sorry for the late response. I had previously read that. The information as presented seems to not be completely correct, however. Specifically, I've not been able to access a DC on separate threads in all situations. For example, it doesn't seem possible to make changes on one thread and then call SubmitChanges on another.

    What I've ended up doing is having one global GUI DC where the user makes changes but SubmitChanges is never called. User changes are collected, and then applied to another DC (inside of a TransactionScope) on another thread where SubmitChanges is eventually called.

    GUI data refresh is accomplished by destroying the existing DC and making a new one.

    Thanks,

     


    -- Bill McCormick ACE-CO
    Wednesday, November 3, 2010 4:23 AM