Re: EOSharedEditingContext
Re: EOSharedEditingContext
- Subject: Re: EOSharedEditingContext
- From: Chuck Hill <email@hidden>
- Date: Thu, 27 Dec 2007 12:19:35 -0800
On Dec 20, 2007, at 10:39 PM, Jonathan Miller wrote:
Fair enough,
But given the scenario where you have a lot of objects that are
going to be read only e.g. the front end of a web site, what is the
best strategy?
0. Don't worry about it until you know it is a problem. Premature
optimization wastes time.
1. Create a session per visitor and use the session's default
editing context.
That is a good way.
2. Constructing a new editing context for everyone component that
fetches objects.
I'd only do that if it is editing the objects.
3. Some other method?
Wonder has some caching classes in ERExtensions. You can cache some
of this at the app level based on globalID.
Chuck
On Dec 20, 2007, at 7:46 PM, Guido Neitzer wrote:
On 20.12.2007, at 21:53, Jonathan Miller wrote:
I've received that advice before, but I've also watched a screen
cast from one of the WWDC events and the apple engineer strongly
recommends using the shared editing context. If I remember
correctly, the engineer stated that iTunes heavily utilizes the
shared editing context.
1. You have about the same knowledge on how to avoid problems with
the sharedEditingContext as the iTunes Store engineers have.
2. You have about the same load on your application the iTunes
Store has and therefor you need the same optimizations.
If these two statements are true for you, you can safely consider
using the sharedEditingContext in your application.
If they are not true, there are so many ways to shoot yourself in
the foot, that *I* would avoid using this peace of ... [personal
opinion deleted]. With the sharedEditingContext you are asking for
trouble.
I also remember all these good recommendations from the various
optimizing WO sessions at WWDC and they are mostly good things but
about 99% of the apps will never need it. Getting around the
problems of these optimizations like added development time,
harder maintenance, nasty bug fixing, unreadable code,
unpredictable deadlocks and so on cause way more trouble than
adding some fancy hardware to your server environment. Just
calculate what a couple of weeks added development time because of
nasty problems add in cost and compare it to better / more server
hardware.
cug
--
http://www.event-s.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden