Local ECs (was Re: Can't modify EO objects! ARGH! =()
Local ECs (was Re: Can't modify EO objects! ARGH! =()
- Subject: Local ECs (was Re: Can't modify EO objects! ARGH! =()
- From: Jonathan Rochkind <email@hidden>
- Date: Tue, 22 Jul 2003 11:01:49 -0500
At 02:55 PM 7/21/2003 -1000, Art Isbell wrote:
Why not carry this to its logical conclusion and use an editing
context for each page as Cocoa does (did?) for each nib? There's nothing
special about the session's default editing context except that WOSession
manages its locks when concurrent request handling is enabled. But as
you've pointed out, who wants to be creating local instances of all the
objects you need in each editing context? It's nice to use a single
editing context when possible.
Well, it's up to you as the developer. I agree that it's nice to use a
single editing context when possible, but I don't personally believe it to
be 'possible' in many cases, without causing problems. Discussion of some
of these cases are what started this thread in the first place---and I know
of no good solution to these sorts of problems other than using 'local' ECs.
Personally, while I'm not familiar with Cocoa at all, I DO use a separate
EC for each _edit_ page. (Currently I use nested ECs, but plan to switch to
peer) That is, a page which has a form on it, with the form values bound
to an EO. For pages which are view-only, there is no reason not to use the
session default. For pages which make changes, but which make immediate
changes in response to a hyperlink button (rather than a form or something
else, which may leave changes waiting around between request-responses), an
argument could be made that you should use a Local EC, but there is less
reason to, and I do not, I just use the defaultEC.
Honestly, while I say that it's up to the developer and the demands of your
particular design, because I want to avoid a 'political' argument----my own
experience has led me to believe that in the vast majority of applications,
you are best off using Local ECs. I believe that D2W does in fact use a
Local EC for every edit page, so apparently some Apple engineers agreed at
some point.
I think for non-D2W applications, the Apple documentation ought to make
clear the purpose and need for Local ECs, and provide instructions to allow
you to use them easily, properly, and effectively. And perhaps some
additional utility objects or API to facilitate this as well.
Using nested ECs, you end up doing something to your single session
default EC, and if you do something that somehow puts the EC in a corrupt
state, that corrupt state is left there for all subsequent uses, and will
keep throwing exceptions. I'm currently dealing with this.
In that case, maybe you could just replace WOSession's default
editing context (setDefaultEditingContext()).
Replace it with what, and when? I'm not sure I'm following you. Enclose
every ec.saveChanges() in a try/catch, and if you are not able to recover
from any exception thrown, throw out the session.defaultEditingContext()
entirely, and call setDefaultEditingContext( new EOEditingContext()
)? Yes, I suppose this would be one solution. As long as you aren't using
any nested ECs----throwing out the parent of an existing nested EC sounds
like a catastrophe waiting to happen.
Alternately, instead of throwing out the EC and setting a brand new one, I
think just calling revert() on it might work as well, perhaps better.
Also, unfortunately, once you start using multiple ECs, you need to take
care of LOCKING them all.
Only if one uses concurrent request handling, right?
Unfortunately, this assumption is not true. I had been operating under
that assumption for a while too, perhaps because I did not want to deal
with locking so it was a convenient fiction. :) Unfortunately, it is a
fiction. Ben Trumball, one of the EOF engineers, has insisted it was not
true for some time, and finally, after reviewing some exceptions in my
logs, I was forced to agree. [I suppose I should have believed him from
the get-go, but I didn't realize he was an EOF engineer till I met him at
WWDC].
I think I can explain at least ONE reason why this assumption is not
true: When an EC receives a notification, it is important that it process
the notification at the proper time. For some types of notifications, the
EC should not be handling them in the middle of other stuff. The way the EC
keeps from doing this is by delaying processing of the notification if the
EC is lock()ed, waiting until the lock is released. If you do not lock
your ECs, notifications sent will be processed at improper times---in a
non-concurrent-request-handling app, this can still occur, notifications
can be sent as a result of some action in the very same session, which
still causes problems when the notifications are received by other ECs
assigned to that same session, if those ECs have not been locked.
I don't completeley understand what's going on, so my explanation may not
make complete sense, but I have exceptions in my logs with stack traces
that lead me to believe something along these lines is going on. Add on to
this that Ben Trumball insists that lack of locking is quite likely to be
the culprit in my exceptions----I am currently working on a general purpose
locking solution.
--Jonathan
And that should be discouraged unless there is absolutely no other
alternative. Few programmers can write bug-free multithreaded
code. Debugging tools are not particularly effective with multithreaded
code. So a huge effort can be required to write and debug multithreaded code.
Aloha,
Art
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.