Re: Multithreading EOAccess
Pierre Bernard <[email protected]>
| Newsgroups | gmane.comp.web.webobjects.eof |
|---|---|
| Message-ID | <[email protected]> |
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... 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. > > >JIM > > >----- Original Message ----- >From: "Pierre Bernard" <[email protected]> >To: <[email protected]> >Sent: Monday, November 18, 2002 3:09 AM >Subject: Multithreading EOAccess > > >> >> >> > ---------- >> > From: Pierre Bernard[SMTP:[email protected]] >> > Sent: Monday, November 18, 2002 3:09:38 AM >> > To: [email protected] >> > Subject: Multithreading EOAccess >> > Auto forwarded by a Rule >> > >> > >> > >> > >> 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 >> > > > --- Spinning WebObjects or cooking up Cocoa in Switzlerland? Let me know: http://homepage.mac.com/I_love_my/