鉴于以上的考虑对Servlet版的测试规划为以下几种测试用例：

　　序号    部署包名（*.JAR *.WAR *.EAR 等）    数据源配置    Weblogic Server

　　的配置    预期结果    说明    可能出现的问题和现象

　　1    ServletQueryForPerConn.war    在每此业务处理时创建数据库连接，操作完毕后关闭并释放。

　　通过Web.xml配置文件来配置JDBC的驱动类型和连接。    直接部署ServletQueryForPerConn.jar部署包。

　　Web容器中只有一个Serverlet实例。

　　建议配置较多的线程数量。

　　性能差。

　　在每此业务处理时创建数据库连接，操作完毕后关闭并释放。

　　此包中没有设计到线程同步的有关代码。    数据库很忙（因为数据库要接收频繁的数据库连接）。

　　可能瓶颈在数据库对频繁的连接处理。

　　数据库事务方面：由于是在每次处理时就调用数据库连接并查询，因此数据库的事务处理应该是单独在一个独立的处理过程中，与并行的其他线程的处理没有关系。

　　2    ServletQueryForOnceConn.war    Servlet对象只是的初始化时连接与数据库的一个连接，在以后的操作中式中使用这个连接。

　　通过Web.xml配置文件来配置JDBC的驱动类型和连接。    直接部署ServletQueryForOnceConn.jar包；

　　Web容器只有一个Servlet实例。

　　建议配置较多的线程数量。

　　性能较差。

　　Servlet对象只是的初始化时连接与数据库的一个连接，在以后的操作中式中使用这个连接。

　　此包中没有设计到线程同步的有关代码。    数据库连接只有一个。

　　可能瓶颈在Web容器的多个线程对同一个数据库连接对象的同步等处理（这些同步处理是Web容器自己管理的）。

　　可能出现查询的数据在多个客户请求中打乱（因为同时使用同一个数据库通信通道）；

　　并且多个线程（单独的处理单元）可能会在同一个处理事务中，可能各个处理单元会串行操作数据库（这要看数据库的具体实现了）。

　　3    ServletQueryForConnPool.war    直接使用Web容器的数据源和数据库连接池。    配置数据源及数据库连接池。

　　建议根据实际情况优化配置数据源和连接池。如可建立多个连接池等配置。    性能好。    Servlet实例不管数据库连接，而是直接从Web容器中取得数据库连接。数据库的连接对象有Web容器全权管理。

　　此包中没有设计到线程同步的有关代码。    对Web容器的数据库连接池的配置可能要根据具体情况进行有效的调整（如数据库连接对象个数和Web容器配额的线程个数的关系等）。如果配置不佳可能是性能瓶颈在Web容器或者在数据库方。

　　4    ServletQueryForConnPool.war

　　（同测试3）    同测试3    Web容器的数据源重新配置为数据库产品专用的JDBC驱动器。    性能好。    测试目的是比较各种不同的JDBC数据连接驱动器的性能，以便得出根据不同的数据库产品选择非常好的的JDBC驱动器。

　　只测试数据库产品提供的专用JDBC驱动器。

　　（说明：因为测试3在理论上性能是最好，因此选用测试3.测试方法和测试3一样，这样才有可比性。）    同测试3.

    5    servletQueryDS_Cache.war    同测试3    同测试3    性能一般

　　使用一变量来缓存查询的数据，用户以后的分页查询查询操作是直接从此缓存中取得的。

　　这种方式对Web容器的内存要求高，效果不是很好，对数据量查询小的效果可能会好些。    优点：

　　减少的了对数据库访问的次数。

　　缺点：

　　需要较大的内存。对Weblogic容器的内存要求高，对于有大量用户的查询操作，并且查询的结果集较大时，可能对整个系统的性能是个很大的瓶颈。

　　对大量数据的分页处理

　　问题描述：

　　背景1：一客户通过IE请求Web服务器查询数据，而查询结果是上千条甚至是上万条记录，要求查询结果传送到IE客户端并分页显示。

　　背景2：一客户通过IE或者其他方式请求Web服务器查询数据，而查询结果是上千条甚至是上万条记录，并要求查询结果把包传送到客户的E-mail中。

　　问：对于这样的有大量数据的结果集，在Web服务器端如何有效的处理？

　　可能涉及到的问题：

　　1.    内存占用

　　大量数据的结果集，可能要

　　2.    传输速度及策略

　　具体的分页处理技术

　　序号    名称    处理方法    针对的数据库    例子说明    备注

　　1    游标查询       直接使用ResultSet来处理。ResultSet是直接在数据库上建立游标，然后通过ResultSet的行位置定位接口来获得指定行位置的记录。

　　当用户第一请求数据查询时，就执行SQL语句查询，获得的ResultSet对象及其要使用的连接对象都保存到其对应的会话对象中。

　　以后的分页查询都通过第一次执行SQL获得的ResultSet对象定位取得指定行位置的记录。

　　最后在用户不再进行分页查询时或会话关闭时，释放数据库连接和ResultSet对象等数据库访问资源。

　　说明：在用例分页查询的整个会话期间，一个用户的分页查询就要占用一个数据库连接对象和结果集的游标，这种方式对数据库的访问资源占用比较大，并且其利用率不是很高。    所有的数据库产品。        优点：

　　减少了数据库连接对象的多次分配获取，减少了对数据库的SQL查询执行。

　　缺点：

　　占用数据库访问资源－数据库连接对象，并占用了数据库上的资源－游标。而这些资源都是十分宝贵的有限制的。

　　结论：

　　这种的数据库查询分页处理方式不是非常好的的。一般不适用这种方式。