none
Correct design for: Multi-Threading & WPF Binding RRS feed

  • Question

  • First off, big thanks in advance for any advice... or just reading all the way through my whole post.

    I am working on a basic C# WPF photo application, that uses SQLCE on the backend to store the photos. I have two threads running to help out. The import thread looks through new files, and enters the thumbnail and metadata into the DB. I have a metadata updater thread that updates the metadata in files and the DB when photos ratings or commetns are added. I have a WPF listview displaying the photos and metadata, and a treeview displaying the different ways you can filter the db. For example you could filter to all photos the have an ISO that equals 400.

    Right now I have this all working using ADO.net and a Dataset that gets passed to the threads. I have the threads lock each table before they change anything. I want to do this with LINQ now. What is the best way?

    - I want the main display to automatically update when new photos are added, through change notification with WPF binding
    - I want any metadata for the photo to automatically update
    - I want to be able to build the treeview items using DISTINCT() queries and have those queries update if new "distinct" items become available... ie a photo is added that has ISO 1600.

    So...

    - Should I have just one data context that is shared by all the threads?
    - If so, do I need to lock the thread? How do I do that, is there an object I should lock onto in the LINQ TABLE?
    - How should I share the data context? Make it global? pass it as a parameter?
    - If I use seperate DataContexts for each thread how do they get synchronized? How would a change on one thread trigger an update to the listview?
    - How will the tables get updated? Do insertions automatically trigger ChangeNotification? Right now I am using a CollectionViewSource for the Photo Listview and that updates when changes are made to the dataset.

    Any suggestions on the best way to go about this?
    Wednesday, September 10, 2008 7:42 PM

All replies

  • The advice I have been given on DataContext is that it should have a short lifetime, and should not be used across threads because it is not thread safe.

     

    As far as updating your WPF control from different threads goes, you cannot simply update it directly.  There are ways to do this in a thread-safe manner -- see the WPF docs for more info.

     

    Sorry if I'm not fully answering your questions.  Hopefully someone else will contribute to this thread.

     

    -Larry

     

    Thursday, September 11, 2008 12:03 AM
  • Thanks Larry! In that case it doesn't seem like it is a good idea to just have one data context for the whole application. With WPF data bindings, they will update if they get a change notification, but I think it might work better on observable collections where the control can tell what has been added and deleted from the collection. I can use the Dispatcher to trigger the UI to refresh a control, but the sometimes also resets the state of the control. It is thread safe though.

    It looks like I might be better off sticking with ADO.net DataSets, instead of LINQ-to-SQL, and instead just use LINQ on some of the internal queries off of the dataset.

    If anyone has a better idea, please let me know!
    Thursday, September 11, 2008 12:59 PM