EC locking/shared snapshots/old data saved
EC locking/shared snapshots/old data saved
- Subject: EC locking/shared snapshots/old data saved
- From: OCsite via Webobjects-dev <email@hidden>
- Date: Fri, 29 May 2020 15:00:30 +0200
Hi there,
just again, I've been bit in my tender parts by the well-known problem that
1. thread A locks its EC
2. thread B saves some change into DB
3. thread A saves its own changes (of different properties), which alas as a
side-effect also reverts B's changes ...
... since A's EC still contains the state before B's changes, and when that
state is compared with the shared snapshot (updated in step 2), the original
outdated object state before B's changes looks like a new change done by A and
thus is saved.
Isn't there some general solution of this problem? I can think of at least
three:
(a) always unlock (and immediately re-lock) EC before saving, preferably
directly in the ERXEC.saveChanges() code (resp. overridden saveChanges of my
own ERXEC subclass, set as er.extensions.ERXEC.editingContextClassName). That,
far as I understand, would merge all the other changes (of which EOF already
well knows due to the notifications, but it can't merge them whilst the EC is
locked).
That would be pretty easy to do, but I am not sure of other dangers which it
possibly might bring? There could be plenty, I am afraid.
(b) implement EC-based non-shared snapshots and use them instead of (or rather
along with) the shared ones to determine what to save into the DB.
That would be considerably more work, again with possible dangers which I can't
quite see now.
(c) invent a scheme with timestamps attached to individual properties in
shapshots and compare them, letting the newest win.
Probably too much at the rube-goldbergish side to be practical.
Has somebody already tried and tested either (a) or (b) or (c) or any other
approach, better than those three, to alleviate this kind of problems with a
success?
Thanks,
OC
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden