对连接池的初步理解

今天研究了下连接池，记录下，以便以后用到。

1)连接池配置

dataSource.setUrl("jdbc:oracle:thin:@192.168.0.10:1521:bks");
dataSource.setUsername("test01");
dataSource.setPassword("123");
dataSource.setDriverClassName("oracle.jdbc.driver.OracleDriver");

dataSource.setInitialSize(10);
dataSource.setMaxActive(1);
dataSource.setMaxIdle(1);
dataSource.setMinIdle(0);
dataSource.setMaxWait(1);

现在了解的是一个连接池中只能配置一个用户进行连接数据库,这里配置的是一个测试用户test01.

2)程序直接从连接池中获取连接,不需要在进行任何用户认证

con = Connpool.setupDataSource().getConnection();
PreparedStatement pstmt = con.prepareStatement("select ID from t01");
ResultSet rs = pstmt.executeQuery();

3)程序开始执行SQL语句,执行完毕后,断开连接.

4)连接池会保持当前的连接不断开,同时也会保持当前的session不断开.

通过如下实验验证了下:

1)开启一个Application,Get an Connection from Connection Pool.
2)Execute an SQL
3)Close the connection
4)Get other connection from Connection Pool
5)Execute other SQL
6)Close the Connection
7)Get the session information from v$session,the session is not closed,and execute all the sql on this session.

下面是记录的SQL结果：

SELECT sid,serial#,sql_text FROM v$session a
JOIN v$sql b
ON a.prev_sql_id=b.sql_id
where username='TEST01';

1241	13516	select ID from t01
1241	13516	select ID from t02

oracle 会通过如下参数进行cached 3次以上的cursor，以便提高性能，避免重新Open an Cursor来执行SQL语句：

SQL> show parameter session_cached_cursors;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ---------------------
session_cached_cursors               integer     20

Note：

1)
SESSION_CACHED_CURSORS specifies the number of session cursors to cache. Repeated parse calls of the same SQL statement cause the session cursor for that statement to be moved into the session cursor cache. Subsequent parse calls will find the cursor in the cache and do not need to reopen the cursor. Oracle uses a least recently used algorithm to remove entries in the session cursor cache to make room for new entries when needed.

This parameter also constrains the size of the PL/SQL cursor cache which PL/SQL uses to avoid having to reparse as statements are re-executed by a user.

2)
If an application repeatedly issues parse calls on the same set of SQL statements, then the reopening of the session cursors can affect system performance. To minimize the impact on performance, session cursors can be stored in a session cursor cache. These cursors are those that have been closed by the application and can be reused. This feature can be particularly useful for applications that use Oracle Forms, because switching from one form to another closes all session cursors associated with the first form.

Oracle checks the library cache to determine whether more than three parse requests have been issued on a given statement. If so, then Oracle assumes that the session cursor associated with the statement should be cached and moves the cursor into the session cursor cache. Subsequent requests to parse that SQL statement by the same session then find the cursor in the session cursor cache.

To enable caching of session cursors, you must set the initialization parameter SESSION_CACHED_CURSORS. The value of this parameter is a positive integer specifying the maximum number of session cursors kept in the cache. An LRU algorithm removes entries in the session cursor cache to make room for new entries when needed.

You can also enable the session cursor cache dynamically with the statement:

ALTER SESSION SET SESSION_CACHED_CURSORS = value;
To determine whether the session cursor cache is sufficiently large for your instance, you can examine the session statistic session cursor cache hits in the V$SYSSTAT view. This statistic counts the number of times a parse call found a cursor in the session cursor cache. If this statistic is a relatively low percentage of the total parse call count for the session, then consider setting SESSION_CACHED_CURSORS to a larger value.