Re: locking editing context
Re: locking editing context
- Subject: Re: locking editing context
- From: Jonathan Rochkind <email@hidden>
- Date: Tue, 11 Feb 2003 11:30:28 -0600
At 05:33 PM 2/10/2003 -1000, Art Isbell wrote:
On Monday, February 10, 2003, at 09:29 AM, Jonathan Fleming wrote:
do you have to lock & unlock the editing context only when you are using
a steless section (directActions) of your application or do you have to
lock & unlock it in state as well?
Locking isn't necessary unless you are writing a multithreaded app.
Writing and debugging a multithreaded app is so difficult that it should
be avoided unless you really have no choice.
This is not what others have told us in the past. We have been told that
ALL apps are multithreaded---even if you don't turn on 'concurrent request
handling', there will be multiple threads, and it's possible that two of
them could be accessing an EO at once. The example frequently given was
posting and handling of notifications. But this is always
controversial---some people insist adamantly that if your app does not have
concurrent request handling turned on, there's no way for two threads to be
accessing the same EOF stack objects at once. Others insist just as
adamantly that this isn't true, and you still need to worry about
locking. I've read the WO 5.2 documents on concurrency and locking, but
they don't clear up the debate to me---especially keeping in mind that WO
documents have been inaccurate in the past.
Myself, I have no idea. I do know that: it seems fairly certain that you
don't need to worry about locking the session().defaultEditingContext()
yourself in usual circumstances. The WO framework takes care of it for
you. I also use nested editing contexts. I have not found a reasonable
design pattern to lock these nested ECs when neccesary in a way that is
reliable and does not result in deadlock, and in a way that doesn't make my
code unacceptably complex. So I have not been locking them---even though
I'm not sure if I'm supposed to or not. My app does not have concurrent
request handling turned on.
I am not sure if this is causing problems for me or not. It is not causing
any obvious problems. But one of my apps does intermittently exhibit some
weird problems that I have been unable to track down, and which may be
related to the fact that I gave up on locking nested ECs.
This whole issue is definitely my biggest annoyance with WO. It would be
nice if Apple provided a definitive explanation of locking of ECs,
addressing both nested ECs, peer ECs, and the defaultEditingContext(), with
and without concurrent request handling, in a clear way. And also providing
example code that handled locking in a way Apple guaranteed was
appropriate. I'm sure someone else will chirp in and say that in fact this
is all obvious and we shouldn't need such documentation, but that's not my
experience. I am using nested ECs in a way _reccomended_ by Apple docs:
http://developer.apple.com/techpubs/webobjects/WebObjects_5/Topics/ProgrammingTopics.39.html
But that document does not address locking, and the other docs that do
address locking---which are improved with the 5.2 documentation---still
leave me unclear about the best way to go about it, and what is neccesary.
--Jonathan
_______________________________________________
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.