Re: Multithreading EOAccess

I had been trying to figure out what lock I should take out before 
modifying the EOModel, even before 5.2 came out. It just seemed like some 
lock would be a good idea before modifying the EOModel. In my case, I am 
modifying the EOModel for the exact reason you mention: to add count(*) 
attributes as needed to entities.

I'm still not sure what the appropriate lock is. However, in WO 5.2 there 
are a number of new lock() methods on EOF stack objects. New methods 
(gotten from the JavaDoc delta reference) include:

EOObjectStore lock() and unlock()
EOObjectStoreCoordinator lock() and unlock()
EODistributedObjectStore lock() and unlock()
EOEditingContext lockObjectStore() and unlockObjectStore()

I don't understand exactly what's going on with the EOF stack enough to 
know which, if any, of these locks would be appropriate to take out before 
EOModel modification. But they are all methods that didn't even exist prior 
to 5.2, when I couldn't even find any candidates for appropriate lock methods.

Does anyone know if any of these would do the trick?  I suppose we could 
experiment to see; but I'm not even sure what the test case is to try and 
force inappropriate concurrency, to see if your lock is properly preventing 
it.

If anyone figures anything out, please do share it with us. I wonder if 
there's any way we can get an opinion from an Apple engineer on this one.

At 01:09 AM 11/18/2002 -0800, you wrote:



>Hi!
>
>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.
>
>
>---
>Spinning WebObjects or cooking up Cocoa in Switzlerland?
>Let me know: http://homepage.mac.com/I_love_my/
>_______________________________________________
>EOF mailing list
>[email protected]
>http://www.omnigroup.com/mailman/listinfo/eof