Well, I don’t know but I think the fact you’d be having this problem points to another problem.
I don’t know your traffic or architecture, but you really should not have that problem at all, I wonder if perhaps you are creating too many separate ECs? I find myself generally putting the bulk of operations into one EC and sometimes creating others for one-off stuff or just because it is a linear process with clear results. Recently I did a lot of invalidating objects based on flags that were likely to require updating from a remote thread, this isn’t a conflict but I did need to ensure those objects were fetched and their contents written over what is in memory. In that case, the user operating the session was really the only part that needed instant updates and only in certain circumstances. Anyway, I’d think about the problem more broadly since I’m personally confident WO/Wonder has the most logical locking and EC handling that has been honed and crafter over decades and used in all kinds of situations. That confidence would lead me to at least try and solve your issues in another way perhaps > On May 29, 2020, at 9:00 AM, OCsite via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > 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 (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com > > This email sent to jtay...@oeinc.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
