Re: WO 5.4, Ajax polling and multi-threading questions
Re: WO 5.4, Ajax polling and multi-threading questions
- Subject: Re: WO 5.4, Ajax polling and multi-threading questions
- From: Karthik N <email@hidden>
- Date: Wed, 18 Feb 2009 07:31:55 -0800
Hi Mike,
Thanks for your insights on EOF and locking. Makes most interesting reading, and hopefully implementing someday soon.
However, in the short-term I need to get the ajax stuff to "just work" in the existing WOA architecture.
This would mean that changes to EOF would not happen.
What I'm trying to achieve is to take a really, really coarse-grained lock on all the existing EOF operations [which will be as bad as today because the WOA is single-threaded]
Conditionally, I'd like to allow the Ajax calls to happen in parallel.
Hence, going back to my first post, do you think this would work?
1. We implement a CustomRequestHandler that extends WODirectActionRequestHandler [All our app alls are DAs]
2. In the CustomRequestHandler#handleRequest() method we conditionally call requestHandlingLock() for all the existing EOF requests and do not lock for the new Ajax ones
Thanks, Karthik
On Wed, Feb 18, 2009 at 6:46 AM, Mike Schrag
<email@hidden> wrote:
we have WO applications that we run single-threaded because "somebody told somebody years ago" that EOF would choke in a multi-threaded environment.
also when i tried to open up multi-threading, i was made to understand that EOF is not thread-safe; EOF is not good at locking and bad things will happen, and hence I need to do the locking myself.
based on what you're describing, it appears that EOF will take care of itself and i don't need to do a thing besides
-WOAllowsConcurrentRequestHandling YES -WOWorkerThreadCountMax 32
looks like i woke up on the right side of bed, if that's the case!
* IMPROPERLY LOCKED eof is not threadsafe
* PROPERLY LOCKED eof is threadsafe (well ... for the most part)
* you should only ever use EOF when you are locking properly
* not sure what "eof is not good at locking" means ... it does not lock on its own (out of the box), so EOF is perfectly good at locking when you tell it to do so
* EOF will NOT take care of itself -- you have to take care of EOF ... if you take care of EOF, it will take care of you, and that means always locking properly
* if you're always using session default editing context (which you should not do), it will lock for you ... if you ever use another EC, you have to lock or you're going to be screwed. this is why Wonder implements automatic editing context locking, which has, for the vast majority of cases, solved this problem. if you don't use Wonder, you should at least be using MultiECLockManager, or something equivalent -- you WILL shoot yourself in the foot otherwise.
* I have never (ever ever) had a WO app that runs with concurrent request handling = false ... it disgusts me to think about it.
so to whomever told you that EOF isn't threadsafe and can be used concurrently: "you're doing it wrong"
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (
email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden