cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: VERY odd exceptions...
Date Wed, 26 May 2004 14:10:51 GMT
Carsten Ziegeler wrote:

> Yes and I think we already went through this hell as we introduced
> the concurrent request counter in which is now only
> enabled if debug logging is enabled.
> In our case this counter is used for disposing a sitemap that has
> been changed. Now we could argue that this might not be a feature
> that is used in production...
> At least, if it creates a bottleneck it should somehow be possible
> to turn this extra syncing off.

Hmm. So you are referring to reference counting as the major mechanism 
here?  :(

Since you already have the Doug Lea Concurrent library (did you upgrade 
to the newest version?) why not simply use a FutureResult?

I did this recently for a database bound Swing app, and the difference 
in perceived performance is incredible.  In order to do this properly,
you would have something like this:

public class MyClass implements Initializable {
	FutureResult m_sitemap = new FutureResult();
	Executor m_executor = // ...;
	// ...

	public void initialize() {
			m_sitemap.setter(new SitemapCallable());

	public void reload() {
		// note: if you want to make all threads wait for
		// us to set up the new sitemap instead of continue
		// to use the old one in the mean time, comment out
		// the following line:
		// m_sitemap.clear();
			m_sitemap.setter(new SitemapCallable());

	public Sitemap getSitemap() {
		Sitemap map = null;

		try {
		} catch (Exception e) {
			// handle it

		return map;

public class SitemapCallable implements Callable {
	public Object call() throws Exception {
		// set up the sitemap

This is much more reliable than reference counting.  Also note that you
could potentially just reload the sitemap every so often without regard
to the last modified date and all will continue to be ok and operate
rather smoothly.

View raw message