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:
1. hold onto a reference to the object as before
2. 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.
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
