Re: Multithreading EOAccess

At 16:58 -0600 11/19/02, Jonathan Rochkind wrote:
>I wrote code that does this, it seems to work---I have yet to have a 
>problem with it. It works. However, I realized that there are 
>potentially problems with concurrency, with editing the EOModel at 
>run time.

You can edit the model at run time.  Just not (reliably) after you've 
started using it.

Since you need to explicitly create new EOObjectStoreCoordinators to 
get concurrent EOF stacks, you should be able to contain the 
concurrency issues.

>This code accomplishes that by duplicating the relationship (as a 
>non-class property) in the EOModel, on-demand, at run-time, with a 
>method called touchRelationship.

Lazy initialization/loading is always a problem with concurrency.

>This code, that I got from others on the list, also doens't seem to 
>be taking out any locks before modifying the EOModel, and even 
>though it seems to work, seems dangerous in the same way.

You can lock all the EOObjectStoreCoordinators.  But that doesn't 
solve the problems with existing snapshots, EOEntity caches, or 
already instantiated EOEnterpriseObjects.  The locking issue is 
something of a mirage.  You're absolutely right that concurrent 
access to the EOModel while it changes at runtime is a problem, but 
it's towards the bottom of the pile.

That's why I suggest making your changes at app start up time, or 
just creating a new EOModelGroup.
-- 

-Ben