I'm not sure why you need access to the NSSaveChangesRequest "transactions" at the application layer?
In your optimistic locking example, your NSIncrementalStore gets a save request at step 5. It tries to commit the changes to the server, but the server comes back and says "transaction back out". Your incremental store constructs an NSError describing the problem and returns nil from -executeRequest:withContext:error:. Your controller code that called -save sees the error, recognizes what it means, and starts the user back at step 1 (presumably by calling refreshObject:mergeChanges: on all the edited objects). Maybe I'm being naive but this seems to complete your scenario. Where did I go wrong? -Noah On Oct 18, 2013, at 9:12 AM, Mikael Hakman <mhak...@dkab.net> wrote: > 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. _______________________________________________ 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
