Q:

Best practice to deal with frequent updates and requests on a Core Data database on iOS?

I am building an application, that will need to gather data from many http sources. Some times, the count of these sources may end up being 700, resulting in a total of 35 MBytes.
To avoid downloading data each time I need it and to avoid charging the user an enormous amount of money, I thought that it would be best to store the results into an SQLite Core Data database, after the first pass, and then perform the requests locally as needed.
I am not searching the best way to avoid crashes while storing the downloaded data. I download data using an operation queue with up to 7 http simultaneous requests, and I fear that I may experience crashes while accessing the same managed object context from 2 threads simultaneously, and since we are talking about physical disk access to store in the database, things may get complicated.
I would just like to know about a good practice to store these kinds of data and then perform fast searches within it, without having your application crashing all the time due to multithreading issues.
Thank you in advance.

A:

You should not have 2 threads accessing the same NSManagedObjectContext. Each thread should have its own NSManagedObjectContext and you should be merging context when necessary using mergeChangesFromContextDidSaveNotification:. Multithreading and Core Data can be tricky so you will need to cross all your T's and dot all your I's on this, but it should be possible. iOS5 brought some better multi-threading support for NSManagedObjectContext with locking and such but I am not familiar with it yet to elaborate, but take a look into the Managing Concurrency section of the class reference if you are targeting iOS5, anything prior to iOS5 you will need to have multiple MOCs.
Also, I believe that when on cellular network iOS limits the device to having a maximum of 2 concurrent HTTP requests at the same time. 

