Re: Locking non default editing contexts in a multithreaded application?
Re: Locking non default editing contexts in a multithreaded application?
- Subject: Re: Locking non default editing contexts in a multithreaded application?
- From: Jonathan Rochkind <email@hidden>
- Date: Thu, 8 Apr 2004 10:49:32 -0500
I can't think of a good way to do this, if you are unwilling to
lock/unlock at the beginning/end of the request (which, you are
right, effectively makes your app no longer handle requests
concurrently).
Where I start thinking about it is: every EOF operation involving
the EC needs to be inside a lock/unlock. But even reading attributes
in an EO counts as an EOF operation for these purpose--someone
correct me if I'm wrong, but in cases where reading EO property
causes a fault to be tripped, I'm sure I'm right, and you generally
don't know if an EOF property read will cause a fault to be tripped,
I think you basically need to assume that that all EO property reads
require a lock. (And even if it doesn't cause a fault to be tripped,
I think it still needs a lock). And of course, changes to EO
properties, as well as operations directly on the EC (fetches,
saveChanges, etc) require a lock.
In appendToResponse, if you have bindings in a component to EOs, you
don't really have control of when EO reads happen, so you need to put
the whole appendToResponse in a lock block. Likewise, in
takeValuesFromRequest, if you have bindings to EOs, you don't really
have control, so you need to put the whole takeValuesFromRequest in a
lock. invokeAction is the only phase where you _potentially_ have
control of when EOF operations happen, so you potentially could get
away with not putting the whole invokeAction in a lock block, but
instead manually lock/unlock before _any_ EOF operations in an action
method. So maybe you could get away with, instead of putting the
whole request-response loop in a lock block, just putting
appendToResponse/takeValuesFromRequest in a lock block, and doing
manual locks in invokeAction. But this isn't much of an improvement;
it would be a pain to implement in invokeAction; and I'm still not
completely confident even this would be enough.
Although, come to think of it, if your app is completely session-less
and all direct actions, _maybe_ there's something less restrictive
you can do. (Maybe takeValuesFromRequest doesn't need a lock around
it, since you can't really bind to EOs in a session-less action;
appendToResponse still does; I'm not sure, this would need to be
thought through very carefully; I don't personally write many
session-less apps, so I don't have a very good feel for it). Let us
know if your app really is entirely session-less direct actions.
Really, though, without doing anything really tricky, I think your
design pretty much requires you to lock the whole request-response
loop, effectively making your app no longer handle requests
concurrently. If this is unacceptable---I think you need a new
design. Perhaps you came up with this design before Apple had
improved the EOF locking system, and documented the need for locks:
in that context, I can understand how your design would seem to make
sense. But now that we are educated about the need for EOF
locking----I don't think it does. I think you need to switch to
using an actual EOSharedEditingContext, along with the special
techniques for making changes that a shared EC requires.
EOSharedEditingContexts don't need to be locked (or at least need to
be locked only in certain circumstances; I forget which; I don't use
EOSharedEditingContext myself much either).
Sorry,
--Jonathan
At 10:12 AM +0200 4/8/04, Nicolas Cassoni wrote:
Hello list,
Although we have read several threads on the topic as well as the available
documentation, one aspect is still unclear.
Indeed, we have an EOEditingContext at the Application level of our app. Our
app responds to direct actions and does quite a few things among which
fetching data in this editing context. It is as if we had a shared
EOEditingContext but with the possibility to write.
Now, the obvious and simple way to handle the locks is to lock when we receive
the direct action and unlock when we return the answer.
Unfortunately, this is a very unefficient way to handle the problem and
defeats the advantage of handling multithreaded requests. Indeed, not all of
the time is spent modifying the editing context.
So... where can we or should we lock?
We could imagin locking each time we call the EOEditingContext to fetch some
objects. But this doesn't handle the problem of a fault firering any time in
our request.
We imagined we could trap some delegated methods or notifications to handle
the lock / unlock. Something like "editingContextWill Change" and
"editingContextDidChange" would be great... simply lock then unlock in those
methods!
Any idea on how to solve the problem? The problem IS a problem as we manage to
easily deadlock our app, unless we implement the global lock/unlock at the
request level (which is an unacceptable solution for us as some parts of the
requests may take seconds independently of editing context access).
Thanks for any help,
Nicolas
--------------------------------------------------------
Nicolas Cassoni
Htpitaux Universitaires de Genhve
Service d'Informatique Midicale
Tel +41 22 372-7566
_______________________________________________
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.