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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
