• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSAtomicStore and multi processes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSAtomicStore and multi processes


  • Subject: Re: NSAtomicStore and multi processes
  • From: Mike Abdullah <email@hidden>
  • Date: Mon, 07 Sep 2015 18:02:33 +0100

> On 26 Jun 2015, at 10:47, Samir <email@hidden> 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 (email@hidden)

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:

This email sent to email@hidden


References: 
 >NSAtomicStore and multi processes (From: Samir <email@hidden>)

  • Prev by Date: Re: 3rd party framework crashes with invalid code sign
  • Next by Date: Re: Auto Layout Problems
  • Previous by thread: NSAtomicStore and multi processes
  • Next by thread: Re: objc_msgSend() selector name: tableView:objectValueForTableColumn:row:
  • Index(es):
    • Date
    • Thread