Add Concurrency Support to CRS Authority

Please see http://docs.codehaus.org/display/GEOTOOLS/Improve+CRSAuthority+Concurrency+Caching+and+Connection+Use for the design under discussion.

In a high-volume environment, geotools does not perform well. This request is to improve the CRS Authority Factories so we can attack them with many many concurrent users and live to tell the tale. We also need to ensure that desktop and scientific applications do not suffer a significant performance hit as a result of this change. The current implementation has a caching technique, and this must be maintained and shown to work as well.

For the sake of discussion we will look at a concrete example, FactoryOnOracleSQL/FactoryUsingOracleSQL (located in /unsupported/epsg-oracle and /library/referencing).

Allowing Multiple Users
1. Use an ObjectPool of workers (ie FactoryUsingOracleSQL)
2. Make FactoryUsingOracleSQL Threadsafe
3. Use Fire and Forget Worker Factory

Cache Handling:
4. Minimalize Connection Use Time
5. Hack Cache to Package Visibility
6. Worker Factory per Thread
7. Isolate Cache into a Separate Object and Inject
8. Seperate out responsibilities so "worker" just provides Definition and does not need the cache

Connection use:
9. Use ObjectPool lifecycle methods
10. Swap out Connection for DataSource
11. Use ConnectionPolicy Stratagy Object

The above solutions have been packaged up as four alternatives on this page:
http://docs.codehaus.org/display/GEOTOOLS/CRS+Authorty+Alternative+Proposals

Worker Pool
-Threads: Use ObjectPool to manage multiple workers

• Cache: Isolate cache into seperate object, and inject into workers so they can perform their own cache check
• Connection: Use ObjectPool lifecycle methods to close connection, tune ObjectPool within limts of provided DataSource

Fire and Forget

• Threads: Create a FactoryUsingOracleSQL as needed in a "Fire and Forget" manner
• Cache: Workers can keep a back pointer, and call the parent to check the cache
• Connection : Workers must limit connection use to just the duration of the executeStatement

Worker DAO Pool

• Threads : Use ObjectPool to manage multiple workers
• Cache : Limit cache use to OracleEPSGAuthority, limit the scope of workers to only providing the definition (not object creation)
• Connection: Use ObjectPool lifecycle methods to close connection, tune ObjectPool within limits of provided DataSource

Just do it:

• Threads: Create a Collection of Workers and manage it ourselves, keeping track of the Thread so we recursively use the same worker
• Cache: Workers can keep a back pointer, and call the parent to check the cache
• Connection: Choose a connection policy strategy object based on a new Hint