Deadlocks, editing context locking and network tasks
Deadlocks, editing context locking and network tasks
- Subject: Deadlocks, editing context locking and network tasks
- From: Mark Wardle <email@hidden>
- Date: Sat, 03 Sep 2016 21:36:10 +0100
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden