Tomcat7.0中配置DBCP连接池以及连接池参数介绍 – 七期提高班-梁焕月博客 – 博客频道 – CSDN.NET.

Tomcat7.0配置连接池的步骤：

• 第一步：在Tomcat的配置文件Tomcat7.0\conf\context.xml中添加信息：

<Context>

    <Resource

      name=”jdbc/drp”

      type=”javax.sql.DataSource”

      driverClassName=”oracle.jdbc.driver.OracleDriver”

      maxIdle=”2″

      maxWait=”5000″

      username=”drp”

      password=”drp”

      url=”jdbc:oracle:thin:@localhost:1521:bjpowernode”

      maxActive=”4″/>

</Context>

• 第二步：把配置文件context.xml剪切到webRoot/META-INF中。(若是只有一个项目使用连接池的话，则剪切到使用连接池项目webRoot/META-INF中。若是多个项目都使用连接池，则不进行操作第二步。)
• 第三步：则在程序中获得连接：

//new DBcP pool

    Context ctx=new InitialContext();

//通过JNDI查找DataSource

     DataSource ds=(DataSource)ctx.lookup(“java:comp/env/jdbc/drp”);

     conn=ds.getConnection();

其中第一步中的上下文context.xml中的参数的解析如下：

  其中的name属性是数据源名称，通常采取jdbc/**.

   type属性是数据源方式。

   driverClassName属性是驱动程序名称。（此文中是oracle驱动程序）

   username，password，数据库名称和密码

   url:访问的数据库路径。其中url的内容组成解析上篇博客中已经分析——Oracle安装以及测试Oracle数据库

   maxActive属性是并发连接的最大数。设置为0则无限制。

   maxWait属性是等待连接的最大连接的时间。

   maxIdle属性是连接池中空闲的连接的个数。

  上文中的设置的 maxActive=”4″说明可以最大连接的个数为4个，再建立连接，则出现异常。

  而maxIdle=”2″说明当关闭数据库时（不是真正的断开连接，而是归还连接池中）连接池中最大可以有空闲的连接数为2个。

  若是再有建立连接，此时若连接池中没有空闲的连接，但是又没有达到maxActive并发的最大连接数，则在连接池中建立连接。

 ps：有些教材Tomcat配置连接池，需要在Tomcat/lib中加入驱动包ojbc14.jar.但是自己在Tomcat7.0下配置连接池时，没有加入驱动jar包依然运行正常。

FitProgrammer@Work: Using Quartz Scheduler in a Java EE Web Application.

At times, you may have wanted to perform some action periodically in your web application. Quartz is an enterprise grade scheduler which can be used for such a task. Read here for the complete list of features of Quartz. For using the Quartz scheduler library in a Java EE web application, following needs to be done:

• Include the quartz jars (quartz-all.jar and others in the lib path). In my case, some of the commons-xxx.jar files were already included in the project due to the dependency of another library (displaytag) on those jar files. So in my quartz setup i had to disinclude them. In the lib/build path, i only included, jta.jar and also everything which was not already there in the project from lib/optional path too (they are not many anyway).

• We then had to create the tables required by quartz for storing job details and triggers across restart of application. This is an optional feature but an important one (which made us decide to use quartz in the first place over the JDK Timer). We used the docs/dbTables/tables_mysql.sql script to create the tables.

• Then we copied (example_quartz.properties), modified and saved the quartz.properties file in the project and changed the packaging settings to include the properties file in the WEB-INF/classes path in the IDE. In the properties file, we changed the configuration to have quartz point to the data store we created in step 2.

• We added following lines to our web.xml:

• Now in our webservice/jsp/servlet of our web application we do the following:

• Of course, the last thing is to write the Job class which does the actual work. The following is code from examples of Quartz.

• Some important points to note about jobs and triggers:

1. Jobs have a name and group associated with them, which should uniquely identify them within a single Scheduler.
2. A Job can be associated with multiple triggers.
3. Triggers are the ‘mechanism’ by which Jobs are scheduled.
4. Many Triggers can point to the same Job, but a single Trigger can only point to one Job.
5. JobDataMap holds state information for Job instances. JobDataMap instances are stored once when the Job is added to a scheduler. They are also re-persisted after every execution of StatefulJob instances.
6. JobDataMap instances can also be stored with a Trigger. This can be useful in the case where you have a Job that is stored in the scheduler for regular/repeated use by multiple Triggers, yet with each independent triggering, you want to supply the Job with different data inputs.
7. The JobExecutionContext passed to a Job at execution time also contains a convenience JobDataMap that is the result of merging the contents of the trigger’s JobDataMap (if any) over the Job’s JobDataMap (if any).
8. We can have different job types:

• Stateful Jobs – where state passed to job (in JobDataMap) is remembered (like static values) across executions of the job. Also, stateful jobs are not allowed to execute concurrently, which means new triggers that occur before the completion of the execute(xx) method will be delayed.
• Interruptable job – provide a mechanism for having the Job execution interrupted by implementing a callback method interrupt(), which will be called when scheduler’s interrupt method is invoked on the Job.