Re: locking editing context
Re: locking editing context
- Subject: Re: locking editing context
- From: email@hidden
- Date: Mon, 24 Feb 2003 09:27:38 -0500
Le mardi, 18 fiv 2003, ` 13:22 America/Montreal, David Neumann a icrit :
> This locking does not prevent using concurrent request handling unless
> ALL of the users in all sessions plan on using the same editing
> context. If your sessions only use the default EC, you don't worry
> about locking.
WO documentation says that editing context takes care of locking the
session store. Correct me if I am wrong, but reading that, I have
concluded that if I lock/unlock at awake/sleep time, then this defeats
concurrent request handing because the database contex is locked for
the full request handling period.
> BTW: I tend to create extra ECs at the Session level and do the
> locking and unlocking in the Session awake and sleep. The request
> handler prevents more than one request from getting access to a
> Session at a time; and you are guaranteed that Session awake and sleep
> trigger just once per request cycle. That's not true of component
> awake and sleep calls. You have a greater potential for a deadlock if
> you do the lock/unlock at the component level:
This is a nice idea. I like that. However, I have a lot of reusable
components, and some of them use local editing contexts. I don't see
how I can actually implement your idea in that case.
If you can prove me wrong with database editing context being locked
for the full request handling period, than I will surely have a second
look at my current procedure, which consists of calling lock/unlock in
try/catch blocks around pieces of code where I think EC need to be
locked. The problem there, of course, is to figure out which calls need
EC being locked and be sure not to forget lock/unlock calls. This is
indeed error prone!
Serge
_______________________________________________
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.