Are you sure no other attributes on the object were dirty in session B to block
the update of the EO from the snapshot?
> 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
