On Oct 17, 2013, at 9:49 AM, Jens Alfke <j...@mooseyard.com> wrote: > But NSIncrementalStore doesn’t have a notion of a transaction, because > CoreData doesn’t care about concurrency, because it’s not multi-user.
This is not the case. - NSIncrementalStore’s notion of a transaction is an instance of NSPersistentStoreRequest, specifically NSSaveChangesRequest. One request is one transaction. - Core Data cares quite a bit about concurrency, a term which typically means in-process use; it was designed from the start with a particular threading model in mind, and revised extensively for OS X 10.7 and iOS 5 to make that threading model much easier to deal with. - Core Data has always cared about multi-user, which really means multiple simultaneous access to a persistent store by multiple persistence stacks (coordinators). That’s the case whether they’re in a single process on one system, in multiple processes on that one system, or in multiple processes on multiple systems. It was designed from the start to use optimistic concurrency specifically to deal with this for incremental persistent stores types like the standard SQLite persistent store. For both concurrency and multi-stack access a persistent store, Core Data’s answers are very similar to the Enterprise Objects Framework: Thread-isolation (use a different context in different threads) and optimistic locking (deal with locking failures on save). -- Chris _______________________________________________ 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
