D
Connection Pools and Java Object Cache in MapViewer

This appendix describes how MapViewer uses Oracle JDBC connection pooling and caching of Java objects to provide efficient performance. The information in this appendix might help you to configure and use MapViewer for the best possible performance on your system.

As described in Chapter 2 and Chapter 3, MapViewer creates a cartographic map in response to a map request based on one or more of the following items specified in a map request: base map, JDBC themes, predefined themes, and geometry features. One or more sets of features from an Oracle database are associated with each of these items (except the inline geometry features), and each JDBC theme can refer to a distinct database. Fetching each set of features from a database sequentially with one JDBC connection would be a slow process, and repeatedly fetching a set of features for the same or different map requests would waste time. To achieve fast response time for each map request and higher server throughput, MapViewer uses Oracle JDBC connection pooling, Oracle Object Cache, and Java threads to perform query processing on one or more back-end databases.

When MapViewer is started in an OC4J instance, it creates a JDBC connection pool manager to maintain a set of JDBC connection pools to handle all JDBC themes in its life span. When a map engine processes a JDBC theme specified in a map request, it checks with the JDBC connection pool manager for a JDBC connection pool to the database that the theme refers to. If one already exists, the map engine gets a JDBC connection from the connection pool to process the JDBC theme. After the process is complete, the map engine returns the connection to the pool rather than closing it. If a JDBC connection pool to the database referred to in the JDBC theme does not exist, the map engine will ask the JDBC connection pool manager to create one and maintain it in its set of JDBC connection pools. There could be more than one JDBC connection pool because there could be more than one JDBC theme in a map request, and those JDBC themes could refer to two or more different databases. All JDBC connections in a JDBC connection pool share one single physical JDBC connection to a database server. It is efficient to reuse the JDBC connection without creating and closing it for each request. After a map engine finishes processing a map request, it closes all associated JDBC connections. This prevents connection leaks that could eventually lock MapViewer.

Whenever MapViewer processes an add_data_source request, it creates a set of map engines for the data source according to the number of mappers specified in the request, and it creates one JDBC connection pool for the map engines to use. When a map engine processes a map request, it gets a JDBC connection from this JDBC connection pool to process each predefined theme in the request.

A map engine uses a thread and a different JDBC connection to retrieve features for each theme specified in a map request, and it synchronizes them to run concurrently. On an application server system with multiple CPUs, this allows MapViewer to provide faster response time and higher system throughput.

In addition, MapViewer uses JDBC Object Cache to cache geometry objects retrieved from the connected databases. MapViewer maintains a set of geometry objects to a predefined volume in memory and on disk. This avoids the need to unpickle (unstream) geometry objects in processing the result set of a spatial query. If a geometry object is in the cache, the cached objects are used directly; otherwise, the geometry object is unpickled and saved in the cache. The behavior of this object cache is set by the attribute values used in the spatial_data_cache element in the mapViewerConfig.xml file. (For more information, see Section 1.5, especially Section 1.5.6.)