EPSG-Oracle Plugin

Research

The epsg-oracle plugin is an experiment focused on cleaning up the JDBC Authority abstract classes to ensure the DataSource can be provided.

IP Review

• http://svn.geotools.org/geotools/trunk/gt/modules/unsupported/epsg-oracle/review.txt

h2 Development Instructions

Setting up For Online Tests

To run this silly module you will need to follow the optional section in the developers guide for Oracle. This will place an oracle jdbc driver into your local maven repository where it can then be used during the online tests.

The other thing you will need to do for online tests is place a file describing your database in a magic location.

Using the Online Test Profile

The choice of profile (to use oracle or to not us oracle) is controlled with a oracle.jdbc system property.

Ideas

Some ideas on the use of DataSource in GeoTools (and how we can set up a testing environment are recorded here): J2EE and Connection Pools

In addition the following problems have been noted ...

org.geotools.referencing.factory:

• AbstractAuthorityFactory - some features are just package-visible (org.geotools.referencing.factory)
  • They were package-private on purpose. They are usually implementation of public API defined somewhere else. We would need to know why access to those implementation class are wanted, and if there is any way to adress the need without making the implementation class public.
• BufferedAuthorityFactory had problem with put(Object, Object) not caching
  • Caching should work, at least in 2.4-SNAPSHOT. Need more details about why caching is considered to not work.

org.geotools.referencing.factory.epsg:

• AuthorityCodes is only package visisble
  • See previous comment about implementation class.
• BursaWolfInfo is only package visible
  • Should NOT be public. This is a very low level implementation detail.
• DataSource - this is WRONG we cannot extend DataSource on our own (we need to use one provided by others)
  • Already deprecated in 2.4-SNAPSHOT for many months. The only reason why it still there is to respect the "deprecate first, delete after next release" cycle.
• DefaultFactory requirements
  • Some kind of DATASOURCE_NAME to work in JBoss (should be configurable)
  • This is already configurable in 2.4-SNAPSHOT through Hints.EPSG_DATASOURCE_NAME.
  • Require DEFAULT_BUFFER_MAX and DEFAULT_PRIORITY_DEC as constructor parameters, either as DefaultFactory(Hints, int, int) to expose the parent constructor, or as new Hints of their own
  • createFactory() needs to wrap the DataSource obtained from JNDI into a class that implements the local DataSource interface.
  • Not needed anymore, since the local DataSource interface is now deprecated.
  • createFactory() cannot bind the DataSource into JNDI (will not always have permission)
  • 2.4-SNAPSHOT already do not bind anymore.
  • createBackingStore() needs to close the JDBC connection obtained from the DataSource (thereby returning it to the pool)
  • We already close the connection (since 2.2 I believe), but after a timeout. The default timeout is 20 minutes. We can change that to a lower level, for example 2 minutes.
  • FactoryUsingAnsiSQL - should not cache the connection (the DataSource will do that)
  • We keep the connection until it is closed by the above-cited timeout. We recreate it from the DataSource after the timeout. 2.4-SNAPSHOT already do that.
  • FactoryUsingOracleSQL - addition to 'AS', the Oracle reserved word 'FILE' is replaced in the query Strings. This necessary because one query uses 'FILE' to rename a column in a SELECT for a column. This factory is used by the AbstractDataSource
  • FactoryUsingSQL - also caches the Connection instead of DataSource
  • TableInfo - not public
  • Again this is a low-level implementation detail that should never be public.

The following bug reports are important:

• http://jira.codehaus.org/browse/GEOT-909 - EPSG DefaultFactory does not work in an EJB environment
  • Need to supply a DATASOURCE_NAME hint - should be of the form "java:EPSG" to keep JBoss happy
  • Already done in 2.4-SNAPSHOT.
  • FactoryUsingSQL should not remove connection from a pool like FactoryUsingSQL does (need to connect and close on each use). Needed for a multi user environment like Java EE.
  • The connection is already closed after a timeout (20 minutes by default, but we can change that). It was already working like that in 2.2.
  • Need to either use a single factory (may become a bottleneck) or use a pool of factories (will need to fix the FactoryUsingSQL connection cache first)
  • We need a single instance of BufferedAuthorityFactory if we want caching to work. It would be possible to update BufferedAuthorityFactory in order to handle many instances of FactoryUsingSQL, but I would like to see if there is really a bottleneck there before to introduce this complication. I was assuming that in typical cases, a user will work with a small set of CRS (~5) appropriate for the area he is working on, in which case many instances of FactoryUsingSQL will not give us much.
• http://jira.codehaus.org/browse/GEOT-908 - FactoryUsingSQL uses Oracle reserved word in query
  • fixed?
• http://jira.codehaus.org/browse/GEOT-907 - Caching in BufferedAuthorityFactory does not work
  • fixed?

Outstanding Issues

This is a research module, and is not currently tracked using Jira. This is however associated with referencing: