[2] The saveChanges operation did not fail and the appropriate R/R loop did end without a glitch, no exception, no problem at all, at 11:00:13.036.
2. user B changed the object; again, we can see for his EC
11:00:25.220 UPDATE on 'DBAuction' ((uid = 1005602) and (lastValidPriceOfferID = 1061695)) -> {lastValidPriceOfferID:1061698}
The saveChanges operation again finished successfully and the appropriate R/R loop did end all right at 11:00:25.424.
3. in a new R/R loop which started at 11:00:40.947, user A read the value (the very standard way through storedValueForKey('lastValidPriceOffer') — which is the one we observe all the time, modelled as a simple :1 relationship with FK lastValidPriceOfferID) —, and got the stale object PK:1061695!
How is it possible that the step 2 did not update values in user A's EC? Incidentally, to make extra sure we do not get stale values even if R/R threads happen to overlap, the code uses in the step 3 looks like this:
synchronized (alock) { // lock for the DBAuction 1005602 object (conceptually on PK to lock out all users regardless their ECs)
try {
auction.editingContext().unlock() // so as to process recent changes from other ECs (thanks, Chuck!)
auction.editingContext().lock() // of course we have to keep it locked
DBPriceOffer wins=auction.lastValidPriceOffer() // simply calls storedValueForKey('lastValidPriceOffer')
println "... last valid $wins"
and this very log shows we have got the old price offer, the one with PK:1061695.
I could understand this if user A changed the object to 1061695 and did not save it (in which case the EC sync would not touch the change; but then it would be all right, if the change was not saved), but he very definitely did save the 1061695 successfully in step 1, and never changed it later (until he got it again — the old/invalid value! — in step 3).
Can anyone see a scenario which would lead to him seeing still 1061695 in step 3, regardless that
- he did save it successfully at 11:00:12 and never changed it later;
- another user did change it to 1061698 and successfully did save at 11:00:25;
- aside of the extra lock/unlock shown above, there is no manual EC locking, ECs are auto-locked at R/Rs;
- and besides, even if the extra lock/unlock was not used, the R/R threads here did not overlap, so the change should be synced all right, and the user should get 1061698 in the step 3?
What do I overlook?
Thanks and all the best,
OC