Re: EC locking/shared snapshots/old data saved
Re: EC locking/shared snapshots/old data saved
- Subject: Re: EC locking/shared snapshots/old data saved
- From: Jesse Tayler via Webobjects-dev <email@hidden>
- Date: Fri, 29 May 2020 09:15:52 -0400
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
> <email@hidden> 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 (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
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