Re: Deadlocks, editing context locking and network tasks
Re: Deadlocks, editing context locking and network tasks
- Subject: Re: Deadlocks, editing context locking and network tasks
- From: Samuel Pelletier <email@hidden>
- Date: Mon, 05 Sep 2016 14:11:40 -0400
Mark,
I discover some useful classes in the er.extensions.concurrency package inside ERExtensions.
Bases on these my current pattern for background tasks is this:
ERXApplication._startRequest();
ec = ERXEC.newEditingContext(parentObjectStore);
try {
do the job without worrying about locks, auto locking will handle then
}
finally {
ec = null;
ERXApplication._endRequest();
}
> 1. For a background thread, it is appropriate to create a new editing context (ERXEC.newEditingContext(Bosc)) using a dedicated and new object store coordinator (created using osc = new ERXObjectStoreCoordinator()).
The new editing context is mandatory, the new OSC depends on your case, as usual there are pros and cons...
Pros:
- You will use a new connection to the database and if your connections settings and use case allows it (do not create long lock in the database server), you will not block others threads of your app.
Cons:
- You will not uses the snapshot cache of the main OSC so everything will be fetched, this can represent a large memory duplication and will require more time if most or your data os already cached.
- Your changes will NOT be propagated to others EOEditingcontexts, they only propagate inside an OSC.
Unless you need to perform long fetch (or update), a separate OSC may is probably not be the most efficient solution. It is really dependant on the type of database access performed by the task.
>
> 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?
You can, see the beginning of the message.
> 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?
That should not be a problem if your EOEditing context is private but you will not receive the change of the EO from others EOEditingcontexts when you are locked. As other said, you should have some timeout in place and handle them properly.
I do not know about too many unlock, I do not expect it to cause problems but I suggest to try, this is easy.
> 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?
As any lock, all resources used will never be released. This will include the snapshot cache of everything fetched in this EC.
Samuel
_______________________________________________
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