Ken,
On 22. 3. 2018, at 0:53, Ken Anderson <kenli...@anderhome.com> wrote:
> Are you sure no other attributes on the object were dirty in session B to
> block the update of the EO from the snapshot?
Actually, yes, pretty sure; for when B saves, _no_ update happens for the EO
'foo'. Unless I am much mistaken, that must mean there were no dirty attributes
in foo at all, right?
(Aside of that, I have always thought that the attributes are merged
individually; i.e., that a dirtiness of attribute 'a' does not prevent
attribute 'b' (which is not dirty) being merged from the snapshot. Was I wrong?)
Thanks a lot,
OC
>
>> On Mar 21, 2018, at 7:41 PM, OC <o...@ocs.cz> wrote:
>>
>> Hi there,
>>
>> long time no see, my problems were plain and easy. Now though I am back with
>> another thing I can't understand.
>>
>> There's an EO with a (string) attribute, let's say foo.value. A number of
>> sessions; session A occasionally sets the attribute, sessions B,C,D ... read
>> it. All happens in default ECs of sessions (not that it, far as I can say,
>> is important). Yesterday's log shows this sequence of events:
>>
>> - A sets (and immediately saves to DB) foo.value "851;21.3.2018 10:48:19"
>> (lucky us, the value indeed happens to contain a timestamp)
>> - B,C,D... all read (a number of times) proper foo.value "851;21.3.2018
>> 10:48:19"
>> - A sets (and saves) foo.value "980;21.3.2018 10:51:07"
>> - B reads (a number of times) OLD foo.value "851;21.3.2018 10:48:19" <-----
>> this is the problem
>> - whilst C,D,... all read proper foo.value "980;21.3.2018 10:51:07"
>> - A sets (and saves) foo.value "1020;21.3.2018 10:52:20"
>> - B,C,D... all read (a number of times) proper foo.value "1020;21.3.2018
>> 10:52:20"
>>
>> Now, do please correct me if I am missing something, but I know of only two
>> cases which would explain the old foo.value in B:
>> (i) the EC has not been unlocked and synced yet. Not the case: B did read
>> the wrong foo.value in a number of subsequent worker threads; besides, it
>> unlocks/locks the EC itself (more to that below);
>> (ii) the foo.value in the EC of B is changed. Not the case either: B saves
>> changes in its EC a number of times; if the value has been changed in there,
>> it would get saved to the DB, which did not happen.
>>
>> Is there any (iii) I have forgot?
>>
>> Now, the code in which the value is read is somewhat non-standard; it needs
>> to ensure some level of serialisation, and thus looks like this:
>>
>> ===
>> EOEditingContext ec=... // the EC of objects we work with, happens to be
>> default EC of session here
>> synchronized (lock) { // only one thread allowed to do this at the same time
>> ec.unlock() // make sure all the changes from other threads ...
>> ec.lock() // ... are properly merged to our EC before we use it
>> ... // some other irrelevant code
>> log "$foo.value" // here the attribute value read from our EO is logged (the
>> one which was wrong for B)
>> ec.saveChanges() // changes made by the other irrelevant code are saved, if
>> any (it would save change of foo.value if any too)
>> }
>> ===
>>
>> Note that the place where A does its foo.setValue(...); ec.saveChanges() is
>> *not* under the lock; there's no need (I believe) to make it serialized.
>> Only the “other irrelevant code” needs that.
>>
>> About the only irregularity I has been able to find with the "980;21.3.2018
>> 10:51:07" was that it happened to been set whilst the session B did perform
>> its synchronized section. It well might have happened in paralel with the
>> “ec.unlock(); ec.lock()” part.
>>
>> I wonder: might it perhaps be possible that, when one EC in a thread A does
>> “ec.unlock(); ec.lock()”, and another EC in another thread at the same time
>> changes (and saves) one of its EOs, that the change would NOT get properly
>> merged to the first EC?
>>
>> If not, well, does anybody have any idea what might be the culprit?
>>
>> Thanks a lot for any advice,
>> OC
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com
>>
>> This email sent to kenli...@anderhome.com
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
