Re: locking editing context
Re: locking editing context
- Subject: Re: locking editing context
- From: David Neumann <email@hidden>
- Date: Tue, 18 Feb 2003 12:22:10 -0600
Hi
Reading it, is seems that I need to lock editing contexts even in the
case of fault resolution. Since fault resolution can happen anytime,
then the only sensible way of managing locking is to lock any editing
context we use at WOComponent.awake time and unlock them in
WOComponent.sleep. In that case, enabling concurrent request handling
does not help unless a significant part of our application's request
make no access to EOs at all.
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.
Also, manually locking/unlocking objects is error prone. And the
resulting errors are the most difficult to fix since they only occur
randomly on heavy load. I really feel that WebObjects should use Java
synchronization to ensure safe OE access without requiring manual
coding. But this would probably mean a considerable rework of
WebObjects...
I used to think along the same lines, but it turns out this would
introduce one hell-uv-a-lot of overhead. You'd have a performance
situation not unlike the original Java collections (BAD). If you can
acquire one lock and then plow through EC and EO API at will until
unlock, you really save some cycles. I'm sure there are others more
enlightened here that can elaborate or correct me here; but this is my
impression.
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:
Transaction starts on one page (lock), then instead of returning that
page after action, you create another page (potential lock again,
deadlock).
The only tricky thing I've run into is if your app uses Long Running
Request Page. That's a case where you get multiple request/responses as
viewed by the session over one logical "request". That is, the status
page will be reloading, but your background job is busy doing its thing
continuously. If it's busy using a EC that is locking and unlocking at
the session awake/sleep you wouldn't get very far without complaints.
So in these cases, if a user enters such a page AND is using a EC, I
disable the automatic session lock/unlock for that EC until the job is
over. Or I create a EC used strictly for the background job.
d
Serge
Le lundi, 17 fiv 2003, ` 14:22 America/Montreal, Brent Shank a icrit :
Perhaps this will help:
http://developer.apple.com/techpubs/webobjects/Enterprise_Objects/
Concurrency/chapter_11_section_3.html
Also, the WebObjects examples are a good source of sample code that
locks and unlocks ec's when needed.
_______________________________________________
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.