Hi all,
I said before that to support dbconfig the goal was to update no client code. Well I lied because there is a situation in which I don’t really see a way around. Thankfully the changes are very mechanical.
The change in question is for singleton objects (like output formats, and DefaultWeb*Service objects) that hold onto the same instance of a ServiceInfo for their life time. An example:
public class DefaultWebFeatureService {
WFSInfo wfs;
public DefaultWebFeatureService(GeoServer gs) {
this.wfs = gs.getServiceInfo(gs):
this.catalog = gs.getCatalog();
}
}
The problem is that once the wfs configuration changes externally the WFSInfo object becomes stale. Now before this was not an issue because the WFSInfo was actually a proxy backed by the real object that lived in memory for the life of the application. But with a db backed config that is not the case. So the WFSInfo object has be look up every time on demand. So the class now becomes:
public class DefaultWebFeatureService {
GeoServer gs;
public DefaultWebFeatureService(GeoServer gs) {
this.gs = gs;
this.catalog = gs.getCatalog();
}
WFSInfo getServiceInfo() {
return gs.getService(WFSInfo.class);
}
}
This pattern is littered throughout the code so unfortunately fixing it requires a lot of updates. However thankfully almost all of the classes take a GeoServer instance in there constructor so no spring config has to change and the change is quite mechanical.
And actually it is only WFS and WCS that suffer from this. When gabriel refactored WMS he did it in a way that always looks up the config object. Go Gabriel!!
Here is the patch that updates the entire code base:
http://jira.codehaus.org/secure/attachment/51461/GEOS-4152.patch
So, any potential downsides. Well one is possibly performance. Since the look up occurs every time the object is needed it comes with a price. However I think this will be negligible because (a) the service objects will probably most of the time be cached and (b) the table backing the services is very small and only has as many rows as there are services, so currently 3 (4 when we hook up WPS). However once the db is not local and over a network these queries are more expensive by an order of magnitude. So in
performance critical areas a workaround will be for the singleton to:
- hold onto a reference to the object as before
- register a listener that clears out and reloads the object only when it changes
I think that should more or less alleviate any issue with cost of the lookup.
So that is the issue. Any feedback or comments welcome. With this change and the catlaog/config dao refactor committed the dbconfig module can land smoothly and start being used.
-Justin
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.