JNDI Datasource HOW.docx
40墨值下载
JNDI Datasource HOW-TO
Table of Contents
Introduction
DriverManager, the service provider mechanism and memory leaks
Database Connection Pool (DBCP 2) Configurations
1. Installation
2. Preventing database connection pool leaks
3. MySQL DBCP Example
4. Oracle 8i, 9i & 10g
5. PostgreSQL
Non-DBCP Solutions
Oracle 8i with OCI client
1. Introduction
2. Putting it all together
Common Problems
1. Intermittent Database Connection Failures
2. Random Connection Closed Exceptions
3. Context versus GlobalNamingResources
4. JNDI Resource Naming and Realm Interaction
Introduction
JNDI Datasource configuration is covered extensively in the JNDI-Resources-HOWTO.
However, feedback from
tomcat-user
has shown that specifics for individual
configurations can be rather tricky.
Here then are some example configurations that have been posted to tomcat-user for
popular databases and some general tips for db usage.
You should be aware that since these notes are derived from configuration and/or
feedback posted to
tomcat-user
YMMV :-). Please let us know if you have any other
tested configurations that you feel may be of use to the wider audience, or if you feel we
can improve this section in anyway.
Please note that JNDI resource configuration changed somewhat between Tomcat
7.x and Tomcat 8.x as they are using different versions of Apache Commons DBCP
library. You will most likely need to modify older JNDI resource configurations to match
the syntax in the example below in order to make them work in Tomcat 8. See Tomcat
Migration Guide for details.
Also, please note that JNDI DataSource configuration in general, and this tutorial in
particular, assumes that you have read and understood
the Context and Hostconfiguration references, including the section about Automatic
Application Deployment in the latter reference.
DriverManager, the service provider mechanism and memory
leaks
java.sql.DriverManager
supports the service provider mechanism. This feature
is that all the available JDBC drivers that announce themselves by providing a
META-
INF/services/java.sql.Driver
file are automatically discovered, loaded and
registered, relieving you from the need to load the database driver explicitly before you
create a JDBC connection. However, the implementation is fundamentally broken in all
Java versions for a servlet container environment. The problem is
that
java.sql.DriverManager
will scan for the drivers only once.
The JRE Memory Leak Prevention Listener that is included with Apache Tomcat solves
this by triggering the drivers scan during Tomcat startup. This is enabled by default. It
means that only libraries visible to the listener such as the ones
in
$CATALINA_BASE/lib
will be scanned for database drivers. If you are
considering disabling this feature, note that the scan would be triggered by the first web
application that is using JDBC, leading to failures when this web application is reloaded
and for other web applications that rely on this feature.
Thus, the web applications that have database drivers in their
WEB-INF/lib
directory
cannot rely on the service provider mechanism and should register the drivers explicitly.
The list of drivers in
java.sql.DriverManager
is also a known source of memory
leaks. Any Drivers registered by a web application must be deregistered when the web
application stops. Tomcat will attempt to automatically discover and deregister any JDBC
drivers loaded by the web application class loader when the web application stops.
However, it is expected that applications do this for themselves via
a
ServletContextListener
.
Database Connection Pool (DBCP 2) Configurations
The default database connection pool implementation in Apache Tomcat relies on the
libraries from the Apache Commons project. The following libraries are used:
Commons DBCP
Commons Pool
of 16
40墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论