Re: Core Data with ODBC databases?
Re: Core Data with ODBC databases?
- Subject: Re: Core Data with ODBC databases?
- From: Mikael Hakman <email@hidden>
- Date: Tue, 22 Oct 2013 01:20:57 +0200
Hello Noah and others,
I have been looking for databases with optimistic transaction control for use with Core Data Persistent Store for ODBC. I found only one such database, the swedish Mimer. All the big names like IBM DB2, MySQL, Oracle and SQL Server use locking. Do you know any other database which uses optimistic?
I got very irritated over this state of the matters. So I have implemented my own optimistic transaction control into my Persistent Store for ODBC. Core Data applications that use my Persistent Store for ODBC can now run with both locking and optimistic databases without locking other users and applications.
/Mikael
On Oct 18, 2013, at 10:23 PM, Mikael Hakman <email@hidden> wrote:
> 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 <email@hidden> 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 <email@hidden> 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 (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
>
>
> _______________________________________________
>
> 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
_______________________________________________
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