Good question - I always that it was on the EO level, not attribute level.
> On Mar 21, 2018, at 8:03 PM, OC <o...@ocs.cz> wrote:
>
> 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
