Re: EOSharedEditingContext
Re: EOSharedEditingContext
- Subject: Re: EOSharedEditingContext
- From: Chuck Hill <email@hidden>
- Date: Thu, 27 Dec 2007 12:17:41 -0800
On Dec 20, 2007, at 9:49 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 have been told by someone that I think should know, that all the
bugs in the SEC are now resolved. Though Anjo may have pointed out
one more. While I have never used the SEC, I think it is safe to use
provided that you use it as intended. The problem is that people see
sharedEDITINGCONTEXT and think EOEditingContext and it is NOT really
an editing context. Then they use it like an editing context and Bad
Things (TM) happen. The SEC can help in some cases, it can hurt in
others.
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.
What Guido said. I have found that in most cases, all that is needed
for sufficient optimization in WO is:
1. Indexes on the database to optimize the common or expensive queries
2. Don't do stupid things in your code.
The best way to verify #2 is to turn on SQL logging and see what your
app is sending to the database. Batch faulting, prefetching, and
ERXRecursiveBatchFetching are sufficient optimization for most
applications.
When this is not enough, you really need to look at what is happening
and get clever to optimize it.
Chuck
--
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