Dear all,
I’m debugging a deadlock and realise that I probably need to re-design some of
my code logic.
Am I right in saying…
1. For a background thread, it is appropriate to create a new editing context
(ERXEC.newEditingContext(osc)) using a dedicated and new object store
coordinator (created using osc = new ERXObjectStoreCoordinator()).
2. For a background thread, all such editing contexts should be lock()’ed and
then unlock()’ed - unlocked in finally {} clause in case of uncaught
exceptions. Automatic locking is only for ECs used within the R-R loop?
3. But what should one do if, either during a background thread, R-R loop
(direct action or component action), one locks an editing context, does some
processing of objects within that context, makes a network call, and then does
some more processing within that context. Should one simply lock() and then
hope for the best, or unlock, do the network process and then re-lock at the
end. Are there any issues running unlock() if the EC isn’t actually locked?
What happens if that network call never returns?
4. Is locking an EC from a newly created OSC completely independent from all
other OSC ECs? If that lock isn’t released for some time, does it matter?
All advice appreciated,
Mark
PS. Using Wonder, using safeLock ERXEC flag in application properties.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
