> On 26 Jun 2015, at 10:47, Samir <samir.edd...@gmail.com> wrote: > > Hi all, > > I’m working on sharing a core data database between multiple processes. > > In the "Core Data Programming Guide”, it’s mentioned that core data databases > does handle multiple processes. > > However, I’m using NSAtomicStore as a persistent store and I’d like to know > if multiple processes can still interact with it (read+write)?
It’s pretty much the same story with Core Data as with any other technology. Something somewhere has got to provide the necessary protections if multiple processes want to access the store (on disk) at once. Out of the box: - The SQLite store relies on SQLite to handle that. SQLite has various clever systems it can use, and which seems to depend a bit on the file system, and the app SDK/deployment target - The other binary stores rely on simple atomic writing of the store to protect from two writers competing and producing a corrupted version of the store. It should be pretty straightforward to do the same for your custom store. The big gotcha though with the second scheme is that if there _are_ two concurrent writers to the store, there’s no merge facility; the last one will win, potentially losing data as it overwrites the previous writer’s result. Likely the best solution there is to add your own locking system on top, such as NSFileCoordination. You also have the issue of hearing about, and handling, when another process modifies the store. Something like NSFileCoordinator again is handy for that. In my experience, Core Data’s built in atomic stores handle the change poorly though, as they’ve cached the previous store version in-memory. It seems you have to remove and re-add the store from the Core Data stack in order for it to flush that cache. Mike. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
