|
|
|
Robert Marianski created |
|
Issue Type: |
|
|
Assignee: |
|
|
Components: |
WFS |
|
Created: |
08/Jun/12 5:39 PM |
|
Description: |
I’m making a wfs request against a geoserver sql view (not a database view) and to generate the response multiple calls are made to retrieve the list of tables from the database. The datastore is oracle in my case, and getting the list of tables is prohibitively slow. Calling it multiple times only exacerbates the issue. I’ve traced through the request, and 3 calls are made during the course of serving up the wfs request. I was using the 2.5 suite version of geoserver. Here’s a rough outline of what’s happening. All the getTables calls are made from the geotools JDBCDataStore::createTypeNames call. But, they all follow a slightly different path to get there. All 3 start from ResourcePool::getFeatureSource. First a check is made to see if the dataStore is a JDBC store and there is a virtual table. If so, then the virtual table is added. This is how the first getTables call gets triggered. Then further down, ResourcePool::getFeatureType is called. Note that false is passed for the second parameter, the handleProjectionPolicy. This method in turn is responsible for the next two calls. The implementation first checks if it is cacheable, which in this case it is not because false is passed in for handleProjectionPolicy. The code then leads to a call to generate the list of type names to find a unique virtual table name. This results in the 2nd getTables call. And finally, the virtual table is added right after, which leads to the 3rd getTables call. I would prefer if getTables wouldn’t be called at all to generate the response. Can the type names be cached? I understand that means as a consequence geoserver will need to be restarted if a new table or view is added to the database, but maybe this could be handled as a configurable policy. And even if it was being cached, perhaps we could provide a way to invalidate it in a live geoserver environment. I’m certainly open to any ideas here. In case it helps, here are the relevant bits of the stack traces for the 3 cases. JDBCDataStore.createTypeNames() line: 842 JDBCDataStore.createTypeNames() line: 842 JDBCDataStore.createTypeNames() line: 842 |
|
Project: |
|
|
Priority: |
|
|
Reporter: |
Major