Re: Multithreading EOAccess

Why wouldn't you modify your model at runtime, only once, just after 
the EOModel has been loaded?

Stéphane

On Wednesday, Nov 20, 2002, at 00:23 Europe/Zurich, Ben Trumbull wrote:

> 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
> _______________________________________________
> EOF mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/eof