Ciao Eric,
let me tell you that your email is a bit convoluted, it tooks me a
while to get around it 
(I am getting old probably).
Your suggestions are interesting but it would not be so
straightforward to implement them (although we might get to that this
summer). A solution for the short term that would
allow you to share the same pool between multiple imagemosaic store
would be to modify the datastore.properties to actually use a JNDI
resource rather than creating its own pool managed by geotools.
You can find an example here:
http://geobatch.geo-solutions.it/download/all/1.3-BETA2/doc/actionImageMosaic.html#using-jndi-on-postgis
In this way you can share the same tomcat pool between many
imagemosaic stores and you can actually publish that index as a layer
per-se via WMS and WFS.
Regards,
Simone Giannecchini
GeoServer training in Milan, 6th & 7th June 2013! Visit
http://geoserver.geo-solutions.it for more information.
Ing. Simone Giannecchini
@simogeo
Founder/Director
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
On Mon, Apr 29, 2013 at 5:42 PM, Eric Smets <eric.smets@anonymised.com> wrote:
Hi,
When in the database.properties of the coverage stores (imagemosaic) with a
timebased
dimension is defined then for each defined layer in the layers the geoserver is
using
one database connection to the database where the index information of the
coverage is stored.
All of the database.property connection string that is used is the same for all
of the defined layers/store.
On average the number of addional layers is growing each day as the geo data is
refering to measurements.
When one have this configuration with 10 measurements a day and one should keep
the defails for 3 months
the resulting database connections that is needed in this design is arround 1000.
- Is there a way in solving this issue with the actual geoserver implementation ?
Wouldn't it be better that in this case the Coverage store parameters can be
build based on two levels
of information/ stores
Step 1: define a postgis store or a geobased store for this index
Step 2: - By defining the coverage store add a parameter where one can
enter the database connection
for the faster retrieval of the gis information
- add the file storage directives as they are used now
By using this type of parameters the coverage store database access could use
the database pooling mechanise as
is used now in the "database" backed layers.
Best regards,
Eric Smets
--
Eric Smets
FKS bvba - Formal and Knowledge Systems http://www.fks.be/
Schampbergstraat 32 Tel: ++32-(0)11-21 49 11
B-3511 Hasselt Fax: ++32-(0)11-22 04 19
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel