• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: just checking...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: just checking...


  • Subject: Re: just checking...
  • From: OC <email@hidden>
  • Date: Tue, 19 Apr 2016 16:09:39 +0200

Samuel,

On 19. 4. 2016, at 15:49, Samuel Pelletier <email@hidden> wrote:

> WOAllowsConcurrentRequestHandling=NO or YES does not have impact on this subject, only the number of live ObjectStoreCoordinator in the app matter.
>
> If you do nat have any external access to the database and a single OSC, you are OK. Changes are propagated to others EOEditingContext under the same OSC during saveChanges, this is the magic part of EOF.

Do please correct me if I am wrong, but I believe this does not happen during saveChanges, but at the end of the R/R loop (or, more precisely, when ECs are unlocked, which normally is at the end of the loop).

Which is why WOAllowsConcurrentRequestHandling has a terrible impact on that.

As always, of course, I migt be missing something of importance.

> If a last modified win policy is OK for the updates, you can even disable them. The goal of the attributes used for locking is to detect an update collision, if you do not care about them, just disable de detection.

Actually the hypothesis I tried to formulate was more like “if an application runs one instance and no background tasks, it would work precisely the same -- be it, depending on the policy, wrong or right -- with or without optimistic locking of anything but PKs”.

Thanks and all the best,
OC

>> Le 19 avr. 2016 à 09:09, OC <email@hidden> a écrit :
>>
>> ... whether I am overlooking something or not.
>>
>> I do think that in a single-instance application with WOAllowsConcurrentRequestHandling=NO and without background tasks is locking of any attribute but PK completely superfluous and can be switched off in the model without any adverse effect.
>>
>> Am I right? Or do I overlook some disaster scenario?
>>
>> Thanks,
>> OC
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list      (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


  • Follow-Ups:
    • Re: just checking...
      • From: Chuck Hill <email@hidden>
    • Re: just checking...
      • From: Samuel Pelletier <email@hidden>
References: 
 >just checking... (From: OC <email@hidden>)
 >Re: just checking... (From: Samuel Pelletier <email@hidden>)

  • Prev by Date: Re: just checking...
  • Next by Date: ERMailDataAttachment and MIME
  • Previous by thread: Re: just checking...
  • Next by thread: Re: just checking...
  • Index(es):
    • Date
    • Thread