Carsten Ziegeler wrote:
Yes and I think we already went through this hell as we introduced the concurrent request counter in Cocoon.java 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_executor.execute(
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_executor.execute(
m_sitemap.setter(new SitemapCallable());
} public Sitemap getSitemap() {
Sitemap map = null; try {
m_sitemap.get();
} 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.
