Andrea Aime a écrit :
> I also would like to notice another thing. The current HSQL provider
> uses more than 4MB or memory to keep a cache of the tables in the
> DB (that's what the profiler reports, HSQL is the single biggest stable
> memory user in GeoServer).
> I find this wasted memory annoying, since most of the GeoServer
> installations would in fact just use 3-10 CRS, but in an Applet
> that would be a real killer.
Yes I noticed that too and I agree that this is a problem. This is one
additional reason to abandon HSQL in favor of an other database. If H2 has a
very close API and performs better on memory usage, I'm all for switching to H2
at least in short term (before the end of this year - we could open a JIRA task
for that).
> Derby has the ability to work out directly of the classpath, but if
> I'm not mistaken, this means it has to load in memory the whole content
> of the db, since random access is not allowed in the classpath, or
> alternatively has to unpack the db contents on a temporary storage.
> The first option would use tons of memory, the second would not be
> any better than the current one.
I don't know how Derby process. I agree that if it behave like that, it would
not be what we are looking for.
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
