Stefano Costa
2017-06-04 16:59:42 UTC
Dear developers,
picking up from this discussion:
http://osgeo-org.1560.x6.nabble.com/PostGIS-Connections-hanging-under-App-Schema-Plugin-td5319085.html#a5319171
I've been working on making App-Schema Data Stores use a single connection
when constructing complex features, no matter how many levels of nested
features must be chained together to do so.
I have a working implementation in this PR:
https://github.com/geotools/geotools/pull/1616
The implementation works only if joining is enabled, which in turn requires
a database backend be used for all joined types, but this is not a
limitation, just the context where this improvement makes any sense.
There is however an actual limitation. To achieve connection re-use among
the many feature iterators required to build a feature containing several
levels of joined types, I've made them share a Transaction instance, as
suggested by Mauro in the discussion linked above, which is then passed to
the underlying JDBCFeatureSource; however, for this to result in the same
connection being used, all the feature sources must have been created by
the same (as in Object.equals) JDBCDataStore.
To achieve this I had to teach AppSchemaDataConfigurator to keep track of
the source data stores created while parsing the XML mapping configuration
(which may be spread over multiple files) and create a brand new data store
only if an existing data store with the same configuration parameters is
not available:
https://github.com/geotools/geotools/pull/1616/files#diff-c8fc7a6b4988b5953aafd9f69af6da98R702
Unfortunately, the "tracking" is done on a per-store basis, so feature
types belonging to different App-Schema data stores will not be able to
share the connection, even if the underlying JDBC data store is actually
the same. I preferred this simpler (but still useful) solution to avoid
introducing a sort of global registry for source data stores.
Does anybody have any further thoughts on this?
Many thanks,
Stefano
picking up from this discussion:
http://osgeo-org.1560.x6.nabble.com/PostGIS-Connections-hanging-under-App-Schema-Plugin-td5319085.html#a5319171
I've been working on making App-Schema Data Stores use a single connection
when constructing complex features, no matter how many levels of nested
features must be chained together to do so.
I have a working implementation in this PR:
https://github.com/geotools/geotools/pull/1616
The implementation works only if joining is enabled, which in turn requires
a database backend be used for all joined types, but this is not a
limitation, just the context where this improvement makes any sense.
There is however an actual limitation. To achieve connection re-use among
the many feature iterators required to build a feature containing several
levels of joined types, I've made them share a Transaction instance, as
suggested by Mauro in the discussion linked above, which is then passed to
the underlying JDBCFeatureSource; however, for this to result in the same
connection being used, all the feature sources must have been created by
the same (as in Object.equals) JDBCDataStore.
To achieve this I had to teach AppSchemaDataConfigurator to keep track of
the source data stores created while parsing the XML mapping configuration
(which may be spread over multiple files) and create a brand new data store
only if an existing data store with the same configuration parameters is
not available:
https://github.com/geotools/geotools/pull/1616/files#diff-c8fc7a6b4988b5953aafd9f69af6da98R702
Unfortunately, the "tracking" is done on a per-store basis, so feature
types belonging to different App-Schema data stores will not be able to
share the connection, even if the underlying JDBC data store is actually
the same. I preferred this simpler (but still useful) solution to avoid
introducing a sort of global registry for source data stores.
Does anybody have any further thoughts on this?
Many thanks,
Stefano