Good thinking Noah, very good indeed. I was blinded by how I currently do things in my Persistent Store for ODBC. You are quite right, when using optimistic transaction control there is no need to commit after fetch request. Committing after save request is enough. Now I know what have to do in my Persistent Store for ODBC. I will not commit after fetch request and I will set the database into optimistic mode. If the database agrees then everything is alright and nice. If the database disagrees because it doesn't support optimistic then we can still run but there will be a chance (or risk) that we lockout other users for a while. This should give us a real tool for some serious work. Good!
BTW, once upon the time, in the 80-ties, I was working with a swedish database vendor who was very proud of their optimistic transaction control. At that time all other database vendors used locking and our customers had difficult to understand how good optimistic transaction control actually is. Nowadays a number of database vendors support optimistic. The swedish vendor is still in business and for developers they provide a database manager free of charge. You can find them at http://developer.mimer.com/platforms/index.tml /Mikael On Oct 18, 2013, at 6:59 PM, Noah Desch <desc...@me.com> wrote: > > 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/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
