Re: Picking up .wo changes
Re: Picking up .wo changes
- Subject: Re: Picking up .wo changes
- From: Pierre Frisch <email@hidden>
- Date: Fri, 6 Jun 2003 08:07:40 -0700
On Thursday, June 5, 2003, at 11:41 PM, Anders F Bjvrklund wrote:
I have two application running that reload the templates on the fly
one from the DB and one from the file system.
What is the benefit of loading templates from the database ?
(assuming that with "templates" you mean the .wo bundles)
In the application that load from the DB I had to give the web designer
the ability to upload site templates. There is an admin application
that enables you to configure the application and upload the templates
and there is a run time application that display them for the enjoyment
of surfers. Storing them in the DB was the logical thing to do.
They have a memory cache like WO but it is under the application
control and I can decide when and what to purge.
Ah, the missing cache control... Do you cache the HTML and WOD
contents too, or just the resulting WOElement ?
I do a double cache similar to the one WO does. I do html and wod cache
so that I don't need to hit the backing store for each component
instantiation and I do an in component caching of the resulting
WOElement to cover the problem with the multiple calls to template()
The one thing to be careful: Your cache must be thread safe.
If I ever want to enable "concurrent requests", you mean ?
Otherwise WebObjects would only be running a single request at a time
anyway, would it not ?
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.
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.