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 protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
