Q:

Core data, what concurrency model to use? 

I am developing iOS an app which will gather big amounts of data from several sources (up to tens of thousands of objects, but simple objects, no images) and save it to my own database using core data.  I then analyse this data and display the results to the user.  
I want to know if there is any benefit to using a Main Queue Nsmanagedobjectcontext or if it is enough that I use a private one. 
I also want to know what the benefit is of having several NSManagedObjectContext or if one is enough? 
The concurrency model i am using currently only has one private queue nsmanagedobjectcontext connected to a persistant store coordinator.  All the data analysis is performed on the private queue and then I simply pass the analyzed data to the main queue to display it.  On older devices (iPhone 4) my application can sometimes crash when too much data is being loaded (i.e. downloaded from the external databases) at the same time, is this related to my choice of concurrency model? 

A:

Your current approach sounds fine.  You only need a main thread context if you want the main thread to interact with the data, and in your case you don't so that's fine. 
Your memory management is effectively unrelated and is more tied to how many things you have going on at once (it sounds like one) and how many objects you try to keep in main memory at any one time (it sounds like many) instead of faulting them out to the data store.  This is what you need to look at / work on.  Instruments can help you see how many objects you're keeping in memory. 
At least call refreshObject:mergeChanges: with NO for merge changes to fault out any objects that you aren't using. 
Also, remember that you're working on a mobile device and that processing up to tens of thousands of objects is a job better handled by a server...

