Hi there,
it so happens I cache a special object of a :N relationship in a fast :1
relationship -- the gist is this:
def theValue() {
def val=this.cacheTo1Relationship()
if (!val)
for (v in this.toNRelationship())
if (somecondition) {
val=v
break
}
return val
}
Should be harmless, should it not? Looks like not.
Well, I am still not entirely sure a I can be missing something of importance,
but far as I can say, it looks like
(i) user (a) loaded the EO, whose cacheTo1Relationship was empty
(ii) user (a) called theValue, which found the desired value, filled in into
cacheTo1Relationship... and, which seems to be the gist of the problem, did not
save immediately his ECTXT, alas, for...
(iii) now _other_ users edited the object and saved their changes for
cacheTo1Relationship
(iv) which updated user (a)'s snapshots (but not his ECTXT.updatedObjects
changes)
This sequence lead to proper disaster when (a) happened to save, much later,
something entirely different: the change from (ii) kicked in. It would be
harmless be the snapshots still original ones (optimistic locking would not let
the stale value to be saved), *but*, alas, since (iv), user (a)'s snapshot
perfectly fit the actual database context and the change was saved.
Does this make sense?
Well I understand that (and why) session.defaultEditingContext is evil, but it
is impractical to fix all the existing, somtimes decades-old code. And besides,
far as I understand the problem properly, it _could_ happen with a temporary EC
just as well, only the opportunity window for it would be much smaller.
Since it does not always make sense to save all changes immediately, is there a
way to prevent this problem? Is it, actually, _reasonable_ to change snapshots
in an ECTXT which contains unsaved changes?
Or am I completely at wrong track, and the cause of my problem (i.e., that very
old and completely stale value has been saved into my cacheTo1Relationship)
must lay elsewhere?
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
