Re: Multithreading EOAccess

>The idea behind having multiple EOObjectStoreCoordinators is to get 
>several independent EOF stacks. True, the EOControl level is 
>duplicated. True, there will be several database contexts and 
>channels. But what about the piece that sits right in-between: the 
>model.

Yup.  Only one.  And only one instance of each EOEntity, 
EORelationship, etc. per EOModel.

>It seems to me that there still is only one model group, one global 
>copy of each model and entity. What I am worried about are tricks 
>that modify an EOModel on the fly. E.g. one common one being to add 
>a "count(*)" attribute to an entity in order to get a row count. I 
>am afraid that such modifications might adversely affect concurrent 
>fetches – either in performance or result.

Well, if you change the set of an EO's class properties mid stride 
during concurrent operations, I'm certain some terrible fate will 
befall your application, eventually.  None of the existing EOs nor 
their EOClassDescriptions are capable of supporting such polymorphic 
behavior.

Even changing not-class properties will likely break snapshoting in 
some horrible way.

>Is there a way to have multiple EOModelGroups – one for each EOF stack?

You can have multiple EOModelGroups.  And you can choose to use only 
one within a specific EOF stack.  It's a fair solution to your 
problem if you really have to do this.  But you'll have to make that 
work yourself.

>Is there any global lock left that one could acquire in situations 
>where one needs to block concurrent EOF operations?

Uhm.  You *want* to block all the other threads ?  The easiest way to 
do this would be to keep a list of all the EOObjectStoreCoordinators 
in the application, and run through the list and lock each.

Can't you perform your dynamic model configuration at start up time 
before creating all the concurrent EOF stacks ?
-- 

-Ben