Both of you, Jens and Chris, are right. Core Data uses transactions internally for each NSFetchRequest and NSSaveChanges request. However, the transactions are not available in the user application. Let's consider the above mentioned banking application - a clerk making a withdrawal or deposit on an account. If your database uses optimistic transaction control then it will do the following:
1. Start a transaction. 2. Fetch account balance from the database. 3. Display balance to the clerk. 4. Let the clerk add or subtract an amount. 5. Update balance in database. 6. Commit transaction. 7. Check transaction error code. 8. if error code is "Transaction back out" or alike then the application should: 9. Inform the clerk. 10. Start all over again from 1 above. It can keep transaction over user interaction because optimistic transactions do not lock anything so that the other users may continue their work. However when you commit, the database checks that all data you have touched (read and updated) is still as it was when you touched it. If so then the transaction is committed, if not the transaction is cancelled and you get "Transaction back out" error. If your database don't use optimistic transactions then it use locking. Now our application has more to do: 1. Start a transaction. 2. Fetch account balance from database. 3. Commit transaction. 4. Store balance value in a variable, oldBalance. 5. Display balance to the clerk. 6. Let the clerk add or subtract an amount. 7. Start a transaction. 8. Fetch account balance from database again. 9. Compare fetched balance with old balance. 10. If the numbers are not equal then the app rollbacks transaction, informs the clerk and starts all over again from 1 above. 11. If the numbers are equal then: 12. Update balance with new value. 13. Commit transaction. Neither of above can be implemented in an application using Core Data. It will commit right after point 2 and 5 in the first application. It will commit right after 2, 8, and 12 in the second application. And in Core Data you cannot start and end transactions from the application. The problem is in Core Data, not in any of its Persistent Stores including my own Persistent Store for ODBC. In order to implement above application you need to use ODBC or equivalent framework/layer directly. This could be done on client or on a server. I think that Apple should add transactions to Core Data. This shouldn't require much work. They only need 2 methods in NSManagedObjectContext , commit and rollback. The NSManagedObjectContext would then pass the method call to actual Persistent Store used. An implementation of a Persistent Store would then start a transaction automatically and commit or rollback on the request from Core Data and thereby from application. I think that Apple by implementing transactions would attract a lot of new developers and users to Core Data. /Mikael On Oct 18, 2013, at 3:18 AM, Chris Hanson <c...@me.com> wrote: > 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/mhakman%40dkab.net > > This email sent to mhak...@dkab.net _______________________________________________ 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
