• Tomcat Driver Oracle
• Tomcat Driver
• Tomcat Diner

The configuration properties for Tomcat's standard datasource resource factory (org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory) are as follows: driverClassName – Fully qualified Java class name of the JDBC driver to be used. MaxTotal – The maximum number of database connections in the pool at the same time. Spring.datasource.tomcat.driver-class-name (String) The fully qualified Java class name of the JDBC driver to be used. The driver has to be accessible from the same classloader as tomcat-jdbc.jar. Spring.datasource.tomcat.username (String) The connection username to be passed to our JDBC driver to establish a connection. The JDBC driver location must be in the Tomcat CLASSPATH. Tomcat runs as a Windows service, so CLASSPATH is set in the registry. If you chose to configure Tomcat when you installed WebFOCUS, the install should have set this for you. To manually set Java Classpath or troubleshoot, check your CLASSPATH field and be sure to include the JDBC driver.

Overview

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 1.x) Configurations.

Apache Tomcat is a Open Source software in the category Servers developed by Apache Software Foundation.

It was checked for updates 377 times by the users of our client application UpdateStar during the last month.

The latest version of Apache Tomcat is 8.0.53, released on 08/24/2018. It was initially added to our database on 10/30/2007.

Apache Tomcat runs on the following operating systems: Windows/Linux.

Users of Apache Tomcat gave it a rating of 5 out of 5 stars.

Write a review for Apache Tomcat!

• » tomcat 8.0 free download
• » apachetomcat server free to download
• » 3.apache tomcat
• » descarga gratuita de tomcat apache
• » apache server 8.0 download
• » download latest version apache tomcat
• » apche tomcat 8.0
• » glasfish network connection inturrupted
• » tomcat alkalmazás letöltése
• » tomcat 7.0.42 download para windows xp

The Tomcat JDBC Connection Pool

Table of Contents

• How to use
• Attributes
• Advanced usage
• Code Example
• Building

Introduction

The JDBC Connection Pool org.apache.tomcat.jdbc.pool is a replacement or an alternative to the Apache Commons DBCP connection pool.

So why do we need a new connection pool?

Here are a few of the reasons:

1. Commons DBCP 1.x is single threaded. In order to be thread safe Commons locks the entire pool for short periods during both object allocation and object return. Note that this does not apply to Commons DBCP 2.x.
2. Commons DBCP 1.x can be slow. As the number of logical CPUs grows and the number of concurrent threads attempting to borrow or return objects increases, the performance suffers. For highly concurrent systems the impact can be significant. Note that this does not apply to Commons DBCP 2.x.
3. Commons DBCP is over 60 classes. tomcat-jdbc-pool core is 8 classes, hence modifications for future requirement will require much less changes. This is all you need to run the connection pool itself, the rest is gravy.
4. Commons DBCP uses static interfaces. This means you have to use the right version for a given JRE version or you may see NoSuchMethodException exceptions.
5. It's not worth rewriting over 60 classes, when a connection pool can be accomplished with a much simpler implementation.
6. Tomcat jdbc pool implements the ability retrieve a connection asynchronously, without adding additional threads to the library itself.
7. Tomcat jdbc pool is a Tomcat module, it depends on Tomcat JULI, a simplified logging framework used in Tomcat.
8. Retrieve the underlying connection using the javax.sql.PooledConnection interface.
9. Starvation proof. If a pool is empty, and threads are waiting for a connection, when a connection is returned, the pool will awake the correct thread waiting. Most pools will simply starve.

Features added over other connection pool implementations

1. Support for highly concurrent environments and multi core/cpu systems.
2. Dynamic implementation of interface, will support java.sql and javax.sql interfaces for your runtime environment (as long as your JDBC driver does the same), even when compiled with a lower version of the JDK.
3. Validation intervals - we don't have to validate every single time we use the connection, we can do this when we borrow or return the connection, just not more frequent than an interval we can configure.
4. Run-Once query, a configurable query that will be run only once, when the connection to the database is established. Very useful to setup session settings, that you want to exist during the entire time the connection is established.
5. Ability to configure custom interceptors. This allows you to write custom interceptors to enhance the functionality. You can use interceptors to gather query stats, cache session states, reconnect the connection upon failures, retry queries, cache query results, and so on. Your options are endless and the interceptors are dynamic, not tied to a JDK version of a java.sql/javax.sql interface.
6. High performance - we will show some differences in performance later on
7. Extremely simple, due to the very simplified implementation, the line count and source file count are very low, compare with c3p0 that has over 200 source files(last time we checked), Tomcat jdbc has a core of 8 files, the connection pool itself is about half that. As bugs may occur, they will be faster to track down, and easier to fix. Complexity reduction has been a focus from inception.
8. Asynchronous connection retrieval - you can queue your request for a connection and receive a Future<Connection> back.
9. Better idle connection handling. Instead of closing connections directly, it can still pool connections and sizes the idle pool with a smarter algorithm.
10. You can decide at what moment connections are considered abandoned, is it when the pool is full, or directly at a timeout by specifying a pool usage threshold.
11. The abandon connection timer will reset upon a statement/query activity. Allowing a connections that is in use for a long time to not timeout. This is achieved using the ResetAbandonedTimer
12. Close connections after they have been connected for a certain time. Age based close upon return to the pool.
13. Get JMX notifications and log entries when connections are suspected for being abandoned. This is similar to the removeAbandonedTimeout but it doesn't take any action, only reports the information. This is achieved using the suspectTimeout attribute.
14. Connections can be retrieved from a java.sql.Driver, javax.sql.DataSource or javax.sql.XADataSource This is achieved using the dataSource and dataSourceJNDI attributes.
15. XA connection support

How to use

Usage of the Tomcat connection pool has been made to be as simple as possible, for those of you that are familiar with commons-dbcp, the transition will be very simple. Moving from other connection pools is also fairly straight forward.

Additional features

The Tomcat connection pool offers a few additional features over what most other pools let you do:

• initSQL - the ability to run an SQL statement exactly once, when the connection is created
• validationInterval - in addition to running validations on connections, avoid running them too frequently.
• jdbcInterceptors - flexible and pluggable interceptors to create any customizations around the pool, the query execution and the result set handling. More on this in the advanced section.
• fairQueue - Set the fair flag to true to achieve thread fairness or to use asynchronous connection retrieval

Inside the Apache Tomcat Container

The Tomcat Connection pool is configured as a resource described in The Tomcat JDBC documentation With the only difference being that you have to specify the factory attribute and set the value to org.apache.tomcat.jdbc.pool.DataSourceFactory

Standalone

The connection pool only has another dependency, and that is on tomcat-juli.jar. To configure the pool in a stand alone project using bean instantiation, the bean to instantiate is org.apache.tomcat.jdbc.pool.DataSource. The same attributes (documented below) as you use to configure a connection pool as a JNDI resource, are used to configure a data source as a bean.

JMX

The connection pool object exposes an MBean that can be registered. In order for the connection pool object to create the MBean, the flag jmxEnabled has to be set to true. This doesn't imply that the pool will be registered with an MBean server, merely that the MBean is created. In a container like Tomcat, Tomcat itself registers the DataSource with the MBean server, the org.apache.tomcat.jdbc.pool.DataSource object will then register the actual connection pool MBean. If you're running outside of a container, you can register the DataSource yourself under any object name you specify, and it propagates the registration to the underlying pool. To do this you would call mBeanServer.registerMBean(dataSource.getPool().getJmxPool(),objectname). Prior to this call, ensure that the pool has been created by calling dataSource.createPool().

Attributes

To provide a very simple switch to and from commons-dbcp and tomcat-jdbc-pool, Most attributes are the same and have the same meaning.

JNDI Factory and Type

System Properties

System properties are JVM wide, affect all pools created in the JVM

Common Attributes

These attributes are shared between commons-dbcp and tomcat-jdbc-pool, in some cases default values are different.

Tomcat JDBC Enhanced Attributes

Advanced usage

JDBC interceptors

To see an example of how to use an interceptor, take a look at org.apache.tomcat.jdbc.pool.interceptor.ConnectionState. This simple interceptor is a cache of three attributes, transaction isolation level, auto commit and read only state, in order for the system to avoid not needed roundtrips to the database.

Further interceptors will be added to the core of the pool as the need arises. Contributions are always welcome!

Interceptors are of course not limited to just java.sql.Connection but can be used to wrap any of the results from a method invocation as well. You could build query performance analyzer that provides JMX notifications when a query is running longer than the expected time.

Configuring JDBC interceptors

Configuring JDBC interceptors is done using the jdbcInterceptors property. The property contains a list of semicolon separated class names. If the classname is not fully qualified it will be prefixed with the org.apache.tomcat.jdbc.pool.interceptor. prefix.

Example:
jdbcInterceptors='org.apache.tomcat.jdbc.pool.interceptor.ConnectionState; org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer'
is the same as
jdbcInterceptors='ConnectionState;StatementFinalizer'

Interceptors can have properties as well. Properties for an interceptor are specified within parentheses after the class name. Several properties are separated by commas.

Example:
jdbcInterceptors='ConnectionState;StatementFinalizer(useEquals=true)'

Extra whitespace characters around class names, property names and values are ignored.

org.apache.tomcat.jdbc.pool.JdbcInterceptor

Abstract base class for all interceptors, cannot be instantiated.

org.apache.tomcat.jdbc.pool.interceptor.ConnectionState

Caches the connection for the following attributes autoCommit, readOnly, transactionIsolation and catalog. It is a performance enhancement to avoid roundtrip to the database when getters are called or setters are called with an already set value.

org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer

Keeps track of all statements created using createStatement, prepareStatement or prepareCall and closes these statements when the connection is returned to the pool.

org.apache.tomcat.jdbc.pool.interceptor.StatementCache

Caches PreparedStatement and/or CallableStatement instances on a connection.

The statements are cached per connection. The count limit is counted globally for all connections that belong to the same pool. Once the count reaches max, subsequent statements are not returned to the cache and are closed immediately.

org.apache.tomcat.jdbc.pool.interceptor.StatementDecoratorInterceptor

See 48392. Interceptor to wrap statements and result sets in order to prevent access to the actual connection using the methods ResultSet.getStatement().getConnection() and Statement.getConnection()

org.apache.tomcat.jdbc.pool.interceptor.QueryTimeoutInterceptor

Automatically calls java.sql.Statement.setQueryTimeout(seconds) when a new statement is created. The pool itself doesn't timeout the query, it is still up to the JDBC driver to enforce query timeouts.

org.apache.tomcat.jdbc.pool.interceptor.SlowQueryReport

Keeps track of query performance and issues log entries when queries exceed a time threshold of fail. The log level used is WARN

org.apache.tomcat.jdbc.pool.interceptor.SlowQueryReportJmx

Extends the SlowQueryReport and in addition to log entries it issues JMX notification for monitoring tools to react to. Inherits all the attributes from its parent class. This class uses Tomcat's JMX engine so it wont work outside of the Tomcat container. By default, JMX notifications are sent through the ConnectionPool mbean if it is enabled. The SlowQueryReportJmx can also register an MBean if notifyPool=false

org.apache.tomcat.jdbc.pool.interceptor.ResetAbandonedTimer

The abandoned timer starts when a connection is checked out from the pool. This means if you have a 30second timeout and run 10x10second queries using the connection it will be marked abandoned and potentially reclaimed depending on the abandonWhenPercentageFull attribute. Using this interceptor it will reset the checkout timer every time you perform an operation on the connection or execute a query successfully.

Code Example

Other examples of Tomcat configuration for JDBC usage can be found in the Tomcat documentation.

Plain Ol' Java

Here is a simple example of how to create and use a data source.

As a Resource

And here is an example on how to configure a resource for JNDI lookups

Asynchronous Connection Retrieval

The Tomcat JDBC connection pool supports asynchronous connection retrieval without adding additional threads to the pool library. It does this by adding a method to the data source called Future<Connection> getConnectionAsync(). In order to use the async retrieval, two conditions must be met:

1. You must configure the fairQueue property to be true.
2. You will have to cast the data source to org.apache.tomcat.jdbc.pool.DataSource

Interceptors

Interceptors are a powerful way to enable, disable or modify functionality on a specific connection or its sub components. There are many different use cases for when interceptors are useful. By default, and for performance reasons, the connection pool is stateless. The only state the pool itself inserts are defaultAutoCommit, defaultReadOnly, defaultTransactionIsolation, defaultCatalog if these are set. These 4 properties are only set upon connection creation. Should these properties be modified during the usage of the connection, the pool itself will not reset them.

An interceptor has to extend the org.apache.tomcat.jdbc.pool.JdbcInterceptor class. This class is fairly simple, You will need to have a no arg constructor

When a connection is borrowed from the pool, the interceptor can initialize or in some other way react to the event by implementing the

method. This method gets called with two parameters, a reference to the connection pool itself ConnectionPool parent and a reference to the underlying connection PooledConnection con.

When a method on the java.sql.Connection object is invoked, it will cause the

method to get invoked. The Method method is the actual method invoked, and Object[] args are the arguments. To look at a very simple example, where we demonstrate how to make the invocation to java.sql.Connection.close() a noop if the connection has been closed

There is an observation being made. It is the comparison of the method name. One way to do this would be to do 'close'.equals(method.getName()). Above we see a direct reference comparison between the method name and static final String reference. According to the JVM spec, method names and static final String end up in a shared constant pool, so the reference comparison should work. One could of course do this as well:

The compare(String,Method) will use the useEquals flag on an interceptor and do either reference comparison or a string value comparison when the useEquals=true flag is set.

Pool start/stop
When the connection pool is started or closed, you can be notified. You will only be notified once per interceptor class even though it is an instance method. and you will be notified using an interceptor currently not attached to a pool.

When overriding these methods, don't forget to call super if you are extending a class other than JdbcInterceptor

Configuring interceptors
Interceptors are configured using the jdbcInterceptors property or the setJdbcInterceptors method. An interceptor can have properties, and would be configured like this

Interceptor properties
Since interceptors can have properties, you need to be able to read the values of these properties within your interceptor. Taking an example like the one above, you can override the setProperties method.

Getting the actual JDBC connection

Connection pools create wrappers around the actual connection in order to properly pool them. We also create interceptors in these wrappers to be able to perform certain functions. If there is a need to retrieve the actual connection, one can do so using the javax.sql.PooledConnection interface.

Building

We build the JDBC pool code with 1.6, but it is backwards compatible down to 1.5 for runtime environment. For unit test, we use 1.6 and higher

Other examples of Tomcat configuration for JDBC usage can be found in the Tomcat documentation.

Tomcat Driver Oracle

Building from source

Building is pretty simple. The pool has a dependency on tomcat-juli.jar and in case you want the SlowQueryReportJmx

A build file can be found in the Tomcat source repository.

Tomcat Driver

As a convenience, a build file is also included where a simple build command will generate all files needed.

Tomcat Diner

The system is structured for a Maven build, but does generate release artifacts. Just the library itself.