Table of Contents
DB@SoL is a JDBC driver that wraps other JDBC drivers. This simple architecture allows to perform operations to enhance database auditing, database performance or to make easier application development.
DB@SoL is a JDBC driver that wraps other JDBC drivers. This simple architecture allows to perform operations to enhance database auditing, database performance or to make easier application development.
Currently, DB@SoL proposes six different drivers for three different RDBMS:
|
(PRODUCTION) |
|
(DEVELOPMENT) |
|
(PRODUCTION) |
|
(DEVELOPMENT) |
|
(PRODUCTION) |
|
(DEVELOPMENT) |
As you can see, there is two types of driver for each supported RDBMS, one for production and one for development.
Production drivers focus on performance issues and database auditing.
Development drivers offer the same functionnalities as production ones plus development features like report for unclosed connection, statement and result set (and automatically close) that help the developer.
Currently, DB@SoL can not be used by application servers through DataSource. The common way is to use Driver#connect( url, properties ).
The parameters are the same as usual:
- the URL of the database to which to connect
- properties used for connection like username, password and so on...
Custom properties can be passed to the DB@SoL driver.
Provides to use one of the following Logger API for message logging:
- Commons-logging
- Log4J
- Java logging
Accepted values are:
- commons-logging
- log4J
- java
Indicates which minimal level to use when logging.
Accepted values are:
- trace
- debug
- info
- warn
- error
- fatal
As you probably know, once a query has been executed, the data must be retrieved (fetched) by the client. Durng this operation, a certain amount of rows are sent by the RDBMS to the client. For example, the Oracle thin driver sends 10 rows to the client in a buffer area of the JDBC driver. Then with each ResultSet#next call, the client retrieves these rows. When the tenth row has been retrieved by the client, the driver retrieves the 10 next rows from the RDBMS. This ensures a lot of network traffic if your query produces a lot of rows.
To enhance performance, the DB@SoL driver tends to increase the fetch size to reach a balance point where the time to retrieve one row is optimal.
On the other hand, the fetch size is limited to 1,000 to avoid out of memory errors!
If a statement execution is too long, it might be because of query design, lack of indexes, locks or other performance related issues.
DB@SoL will log all the statements if their execution duration has reached a threshold (which can be parametrized).
Unclosed connection can bring a lot of problem to a RDBMS: lock, lack of ressources, bad response time.
To avoid this problem, DB@SoL registers each created connection in a WeakHashMap object. It permits to detect when a connection can't be used anymore (no more referenced). If such connection is not closed, DB@SoL generates an alert in the log file; and closes all the possible statements or result set not closed then it closes the connection.
Reporting of such alert tells where the connection has been retrieved in the developer source code from the driver. If the -g option has been used for code compilation, it even tells the line where the connection has been instanciated!