On Sat, Oct 2, 2010 at 12:58 AM, Justin Deoliveira <[email protected]> wrote: > Here is the patch that updates the entire code base: > http://jira.codehaus.org/secure/attachment/51461/GEOS-4152.patch
Saw this mail after reviewing the patch, I added comments in the jira. > 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. I believe we don't want the config and catalog to query like crazy a remote dbms, each round trip is expensive if compared to the time we take to render a GetMap request in the typical benchmarking setup (which is something like 50ms total). Ideally, both should use some 2nd level caching setup, possibly cluster aware, configured so that the actual hits to the database are reduced to a minimum. Some references: * http://ehcache.org/documentation/hibernate.html * http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-cache (not how the newest ehcache should also be cluster safe, see the faq in the ehcache docs). Well, just some ideas, I did not look in the details of how to add it or to make this admin configurable (and so on), but it would seem a promising road. If people want to hit the db directly and change the config there they would also have to notify the 2nd level cache about the changes somehow. Which brings me to a question: the on disk xml configuration is not the recommended way to alter the config. What will be our stance towards the database one? If we just say to go and use restconfig the clustered cache should handle dropping dirty items automatically, however I guess the config should be extended to allow editing services as well. Cheers Andrea ----------------------------------------------------- Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ----------------------------------------------------- ------------------------------------------------------------------------------ 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
