Re: Multithreading EOAccess

On Lunedì, nov 18, 2002, at 17:18 Europe/Rome, Pierre Bernard wrote:

> Jim,
>
> that's easier said than done. I agree that changing the model is not a 
> good idea. However I get the evre increasing feeling that there is 
> stuff in the EOModel that is not strictly part of what I woudl 
> consider the model of database mapping.
> E.g. there are flags that influence caching behavior. That's something 
> I'd typically might want to be different for some applications or 
> sessions. Maybe and admin should get to see only fresh data. Maybe one 
> user can only modify a given entity and all others should be read-only 
> and cached...
>

Agreed. That's one of my pet features :-).
However, one can assume that changing something like caching options or 
anything that should be configured at run time, is safe only when the 
EOModelGroup.ModelAddedNotification is posted, IMHO.


> Pierre.
>
>
> On Monday, Nov 18, 2002, at 04:08PM, James Klett 
> <[email protected]> wrote:
>
>> Peirre,
>>
>> Do not modify the Model.  This is bad behavior.  Suppose I am the 
>> database
>> designer, I provide you with a model.  You are supposed to use that 
>> model
>> the way I give it to you.  But instead you cheat, this is bad.  Use a 
>> stored
>> procedure instead.
>>
>>
>>>
>>> Now that concurrent EOF operations are again possible by having 
>>> multiple
>> EOObjectStoreCoordinators there are some 'smart tricks' we are using 
>> that
>> have me worried.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Is there a way to have multiple EOModelGroups - one for each EOF 
>>> stack?
>>> Is there any global lock left that one could acquire in situations 
>>> where
>> one needs to block concurrent EOF operations?
>>>
>>> Pierre.


Giorgio Valoti
------------------------------------------------------
Magnetic Media Network:
<http://www.magneticmedia.com>
------------------------------------------------------
Public folder
<http://homepage.mac.com/giorgio_v/FileSharing1.html>
------------------------------------------------------