Re: Thread safety in WO (was Re: Picking up .wo changes)
Re: Thread safety in WO (was Re: Picking up .wo changes)
- Subject: Re: Thread safety in WO (was Re: Picking up .wo changes)
- From: Hsu <email@hidden>
- Date: Mon, 9 Jun 2003 21:40:26 -0700
The WebObjects WODefaultAdaptor is always multi-threaded, but the
request-handling is not (by default).
This means that WORequests will be read in parallel, processed
according to WOAllowsConcurrentRequestHandling (default to false), and
returned in parallel.
Karl
On Monday, June 9, 2003, at 09:42 AM, Jonathan Rochkind wrote:
At 08:07 AM 6/6/2003 -0700, Pierre Frisch wrote:
Concurrent request handling is the default behavior in WO 5.x and I
would not bank to much on the ability to disable it. I remember
reading somewhere that WO 5.x is always multithreaded and that you
should never make the single thread assumption.
Hm. It's true that WO 5.x is always multithreaded, in that more than
multiple threads will always exist at once. I do NOT think it's true
that WO 5.x handles requests concurrently by default. The
documentation for WOApplication.allowsConcurrentRequestHandling says
"returns false by default."
The trick then, when you know that requests will not be handled
concurrently but that the app is multithreaded, is figuring out in
what circumstances more than one thread may be accessing any given
piece of code. And I'm not always sure. Various knowledgeable
developers who I respect have disagreed on this sort of thing on the
list in the past.
For a piece of code that actually spans sessions, like an
application-wide cache of WOElement definitions, I would agree that to
be on the safe side you better write it in a thread-safe way, assuming
the worst case in terms of multiple threads wanting to access it at
once.
--Jonathan
Something like this should do, should it not: (well, I have to load
the strings from somewhere too)
WOElement cachedTemplate;
public WOElement template()
{
if (cachedTemplate == null)
{
synchronized(cachedTemplate)
{
if (cachedTemplate == null)
cachedTemplate =
templateWithHTMLString(htmlString, wodString, languages);
}
}
return cachedTemplate;
}
This would address one level of cache. You probably would like to
cache the hit to the backing store when instantiating new components.
You want to implement that with Dictionaries based on component name
and language. I usually do a double level dictionary the first level
is based on the component name and the second on the language. When a
search is unsuccessful you probably want to tag it so as not to redo
it.
Or perhaps I'll just forget about it all, and go back to PHP and
MySQL again...
At least there I can look at the source code, if I wonder about
something.
If you don't care about performance, you don't need caching and all
is simple....
--anders
_______________________________________________
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.
--
Easy there, I know over two hundred ways to kill a man.
You could glue an open jar of rats to his face, then blowtorch the
other side so the rats have to eat their way through his face.
... Two hundred one, then.
Homepage:
http://homepage.mac.com/khsu/index.html
_______________________________________________
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.