How should I use EF4 in a Threaded WinForms app?

I've got a winforms app which just reads log files. Now, because I have a couple of log files (say, 20-30), I've tried to make the winform app threaded, so it can read multiple log files at once.

But i'm not sure how I should be handling the saving of the log file data.

1. One Context Per Thread

For example, should each threaded log file that is parsed, have it's own EF4 context and does the save (eg. every 1000 records or when EOF)

or

2. One Context for the WinForm Thread

Should the winform app have the single context an each background thread report back with a collection of log file entries and the main winform thread saves it every x records or x seconds or something...

I'm just not sure where I should be putting the context ... and 开发者_StackOverflow社区more importantly ... why I should put it where ever.

Does anyone have any suggestions?

Basically, a EF context can only be used from the thread that created it. Some things might work as expected if you use the context accross threads, but there is no guarantee, as ObjectContext is not thread-safe according to the documentation. For instance, lazy loading doesn't seem to work accross threads.

To answer your question, I think your first option (one context per thread) is the best (provided you limit the number of concurrent threads). Having all worker threads calling the form to insert the data would freeze the UI and prevent worker threads from working efficiently.

I think both approaches are valid. When every thread processed separate logdata, you can go all the way to the database and use one EF context per thread and let your rdbms handle the concurrency issues.

If you are concerned about performance, you have to measure which approach performs better. That might depend mainly on your database system / table layout.