lingfang_yan 的 asp.net session的应用

Session又称为会话状态，是Web系统中最常用的状态，用于维护和当前浏览器实例相关的一些信息。举个例子来说，我们可以把已登录用户的用户名放在Session中，这样就能通过判断Session中的某个Key来判断用户是否登录，如果登录的话用户名又是多少。

我们知 道，Session对于每一个客户端（或者说浏览器实例）是“人手一份”，用户首次与Web服务器建立连接的时候，服务器会给用户分发一个 SessionID作为标识。SessionID是一个由24个字符组成的随机字符串。用户每次提交页面，浏览器都会把这个SessionID包含在 HTTP头中提交给Web服务器，这样Web服务器就能区分当前请求页面的是哪一个客户端。那么，ASP.NET 2.0提供了哪些存储SessionID的模式呢：

·      Cookie（默认）。如果客户端禁止了Cookie的使用，Session也将失效。

·      URL。Cookie是否开启不影响Session使用，缺点是不能再使用绝对链接了。

前面说了SessionID可以存储在客户端的Cookie或者URL中，那么Session真正的内容存储在哪里呢？ASP.NET 2.0对于Session内容的存储也提供了多种模式。

·      InProc（默认）。Session存储在IIS进程中（Web服务器内存）。

·      StateServer。Session存储在独立的Windows服务进程中（可以不是Web服务器）。

·      SqlServer。Session存储在SqlServer数据库的表中（SqlServer服务器）。

虽然 InProc模式的Session直接存储在Web服务器IIS进程中，速度比较快，但是每次重新启动IIS都会导致Session丢失。利用后两种模式，我们就完全可以把Session从Web服务器中独立出来，从而减轻Web服务器的压力，同时减少Session丢失的概率。

因此，SessionID存储在客户端（可以是Cookie或者URL），其他都存储在服务端（可以是IIS进程、独立的Windows服务进程或者SQL Server数据库中）。

12.3.2  Session的使用

让我们先来实践一下如何使用Session，进而回答第二个问题：Session存储的类型限制。Session不需要进行任何配置就可以使用（默认是InProc模式并且依赖Cookie）。首先，在页面上建立两个按钮。

<asp:Button ID="btn_WriteSession" runat="server"Text="写入Session" />

<asp:Button ID="btn_ReadSession" runat="server" Text="读取Session" />

在btn_WriteSession按钮的Click事件处理方法中，写入两个Session，一个是简单的字符串，另外一个是自定义的类。

protected void btn_WriteSession_Click(object sender, EventArgs e)

{

    Session["SimpleString"] = "编程快乐";

    MyUser user = new MyUser();

    user.sUserName = "小朱";

    user.iAage = 24;

    Session["CustomClass"] = user;

}

Session的使用非常简单，直接对某个Key的Session进行赋值即可。自定义类MyUser如下：

class MyUser

{

    public string sUserName;

    public int iAage;

    public override string ToString()

    {

        return string.Format("姓名：{0}，年龄：{1}", sUserName, iAage);

    }

}

在这里，我们覆写了ToString()方法直接返回实例的一些信息。然后，双击btn_ReadSession按钮来实现从Session中读取数据的代码：

protected void btn_ReadSession_Click(object sender, EventArgs e)

{

    if (Session["SimpleString"]==null)

    {

        Response.Write("读取简单字符串失败<br/>");

    }

    else

    {

        string s=Session["SimpleString"].ToString();

        Response.Write(s + "<br/>");

    }

    if (Session["CustomClass"]==null)

    {

        Response.Write("读取简单自定义类失败<br/>");

    }

    else

    {

        MyUser user=Session["CustomClass"] as MyUser;

        Response.Write(user.ToString()+"<br/>");

    }

}

在每次读取Session的值以前请务必先判断Session是否为空，否则很有可能出现“未将对象引用设置到对象的实例”的异常。我们看到，从Session 中读出的数据都是object类型的，我们需要进行类型转化后才能使用。打开页面，先单击写入Session按钮，再单击读取Session按钮，页面输出如    图12-1所示。

12.3.3  把Session存储在独立的进程中

由此看来，Session能存储任意对象，是这样吗？现在得出这个结论还太早了一点，因为我们并没有实践过StateServer和SqlServer模式的Session。要把Session存储在Windows服务进程中需要进行以下几个步骤。

n  第1步是打开状态服务。依次打开“控制面板”→“管理工具”→“服务”命令，找到ASP.NET状态服务一项，右键单击服务选择启动，如图12-2所示。

图12-2  启动ASP.NET状态服务

n  如果你正式决定使用状态服务存储Session前，别忘记修改服务为自启动（在操作系统重启后服务能自己启动）以免忘记启动服务而造成网站Session不能使用，如图12-3所示，双击服务把服务的启动类型设置为自动。

图12-3  修改服务启动类型为自动

服务正常启动后可以观察任务管理器的进程页，其中的aspnet_state.exe进程就是状态服务进程，如图12-4所示。

图12-4  观察任务管理器的进程页

n  第2步，在system.web节点中加入：

<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424"

stateNetworkTimeout="20"></sessionState>

n  stateConnectionString表示状态服务器的通信地址（IP：服务端口号）。由于我们现在在本机进行测试，这里设置成本机地址127.0.0.1。状态服务默认的监听端口为42422。当然，您也可以通过修改注册表来修改状态服务的端口号。

n  1．在运行中输入regedit启动注册表编辑器。

n  2．依次打开HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters节点，双击Port选项，如图12-5所示。

选择基数为十进制，然后输入一个端口号即可。stateNetworkTimeout属性表示从状态服务器请求Session数据最长的时间，默认为10秒，如果网络连接不是很好，请把这个数字适当设置得大一点。

n  第3步打开页面，单击“写入Session”按钮，系统会报错，如图12-6所示。

   

        图12-5  修改状态服务端口号            图12-6  向StateServer默认的Session中写入自定义类出错

提示已经说得很清楚了，只有把对象标注为可序列化后才能在服务中进行存储。什么是序列化呢？序列化是指将对象实例的状态存储到存储媒体的过程。在此过程中，先将对象的公共字段和私有字段以及类的名称转换为字节流，然后再把字节流写入数据流。在随后对对象进行反序列化时，将创建出与原对象完全相同的副本。要使一个类可序列化，最简单的方法是使用 Serializable 属性对它进行标记。

[Serializable]

class MyUser

{

    public string sUserName;

    public int iAage;

    public override string ToString()

    {

        return string.Format("姓名：{0}，年龄：{1}", sUserName, iAage);

    }

}

n  第4步现在重新打开页面进行测试，得到的结果和使用InProc模式是一样的。

12.3.4  把Session存储在数据库中

要把Session存储在SqlServer中，基本上也是这么几个步骤。

n  1．在命令行窗口输入cmd并在命令行中运行如下命令。

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql.exe -S .\SqlExpress -E –ssadd

其中 C:\Windows用你自己Windows的目录代替，v2.0.50727用你安装的2.0框架的版本号代替。-S指定SqlServer服务器地址，-E表示采用信任连接，-ssadd表示为SqlServer服务器添加状态服务的支持。操作结束后，你可以使用IDE的服务器资源管理器连接 SqlExpress数据库，可以看到多了一个ASPState数据库，但是奇怪的是数据库中没有任何表却有很多存储过程，如图12-7所示。

其实，所有Session的数据都存放在了tempdb数据库内，如图12-8所示。

           

    图12-7  使用服务器资源管理器浏览ASPState数据库      图12-8  存放Session数据的tempdb数据库

其实，aspnet_regsql.exe有一个-sstype参数可以用来指定Session的内容和操作的存储过程存放的表。由于篇幅关系，在这里就不详细介绍了，读者可以使用aspnet_regsql.exe/?来浏览程序详细的使用方式。

n  2．打开Web.config文件，修改前面建立的sessionState节点。

<sessionState mode="SQLServer" sqlConnectionString="server=(local)\SQLEXPRESS;

Trusted_Connection=True" sqlCommandTimeout="60"></sessionState>

为sqlConnectionString 属性指定以前一直用的连接字符串，唯一不同的是不需要再指定数据表的名字了。sqlCommandTimeout属性表示允许执行Sql命令最长的时间，默认为30秒，可以根据自己的需要适当调整这个数字。最后，重新打开页面进行测试，得到的结果和使用InProc模式是一样的（同样你需要确保在自定义类前标注了[Serializable]），不过我们能感到速度有些慢了，毕竟数据是从数据库中进行读取或保存的，而且在使用前还需要经过序列化和反序列化操作。

因此Session能存储的类型为： 对于InProc模式是一切类型，而对于StateServer和SqlServer模式是一切可以序列化的类型。

12.3.5  Session的使用范围与大小限制

那么， 会话状态使用的范围和大小限制又是怎么样的呢？我们可以分析一下图12-8，系统使用两个表来存储Session的状态。其中有一个 ASPStateTempApplication表，用来存储Session所在的应用程序，一定程度上反映了Session是不能跨应用程序的。举例来说，我们在计算机上建立了两个网站，同时都使用Session[“UserName”]来保存登录的用户名，一个网站的用户登录后，另一个网站直接访问 Session[“UserName”]是取不到任何值的。那么，Session是否可以跨用户呢？通过前面的分析我们知道，肯定是不行的， Session通过SessionID来区分用户，一般来说SessionID是不可能出现重复的现象，也就是说Session一般是不会“串号”的。既然页面每次提交的时候都会附加上当前用户的SessionID，那么Session应该是可以跨页面的，也就是说一个网站中所有的页面都使用同一份 Session。你可以自己来做个试验，请读者打开刚才那个页面，然后按Ctrl+N组合键再打开第二个同样的页面，单击第一个页面中的“写入 Session”按钮，单击第二个页面中的“读取Session”按钮，可以发现Session的值被正确读出了。第三个问题的答案有了。

·      Session状态使用的范围：使用同一个客户端（浏览器实例）访问同一个应用程序的所有页面。

我们再来做一个试验，看看Session的容量有多大，在测试以前请修改Web.config，把Session设置为StateServer模式。然后，把写入Session的代码修改成如下（别忘记using System.Data.SqlCient）：

DataSet ds = new DataSet();

using (SqlConnection conn = new SqlConnection(@"server=(local)\SQLEXPRESS;database=Forum;

Trusted_Connection=True"))

{

    SqlDataAdapter da = new SqlDataAdapter("select _* from tbUser;select _* from tbBoard;

    select _* from tbTopic;", conn);

    da.Fill(ds);

}

ArrayList al = new ArrayList();

for(int i = 0;i<10000000;i++)

    al.Add(ds);

Session["LargeData"] = al;

我们把包含三个表的DataSet重复加入ArrayList中1000万次。由于这些表几乎每个表只有几条记录，这样可以模拟大数据量的情况。启动页面，单击“写入Session”按钮后可以发现，Windows服务进程一下子占用了多达70MB的内存，如图12-9所示。

图12-9  把大量数据存放到Session中

Session 对于网站和用户是独立的，试想一下，如果服务器上有两个网站，每个网站的在线人数是100人，那么占用内存就要14G。是不是很恐怖的数字？因此，虽然 Session的大小没有限制，但是我们千万不能滥用Session。笔者推荐你在Session中存储少于100K的数据。

·      如果你使用InProc模式的Session，存储过多的数据会导致IIS进程被回收，引发Session不断丢失。

·      如果你使用StateServer存储Session，那么数据在存入Session以前需要进行序列化，序列化会消耗大量的CPU资源。

·      如果你使用SqlServer模式的Session，数据不但要序列化而且还是存储在磁盘上，更不适合存储大量数据。

12.3.6  Session的生命周期

在了解了Session中存储的数据无大小限制后，我们可能要更多地关心Session的生命周期了。我们已经知道，Session是在用户第一次访问网站的时候创建的，那么Session是什么时候销毁的呢？Session使用一种平滑超时的技术来控制何时销毁Session。默认情况下，Session 的超时时间（Timeout）是20分钟，用户保持连续20分钟不访问网站，则Session被收回，如果在这20分钟内用户又访问了一次页面，那么20 分钟就重新计时了，也就是说，这个超时是连续不访问的超时时间，而不是第一次访问后20分钟必过时。这个超时时间同样也可以通过调整Web.config 文件进行修改：

<sessionState timeout="30"></sessionState>

当然你也可以在程序中进行设置：

Session.Timeout = "30";

一旦Session超时，Session中的数据将被回收，如果再使用Session系统，将给你分配一个新的SessionID。本节一开始我们就介绍了可以在URL中存储SessionID，现在请你配置Web.config文件，设置Session超时时间为1分钟，SessionID在URl中存放。打开页面后单击“写入Session”按钮，过1分钟再次单击按钮并观察SessionID是否变化。

<sessionState timeout="1" cookieless="true"></sessionState>

如图12-10所示，SessionID的确发生了变化。

图12-10  超时后SessionID发生变化

不过，你可别太相信Session的Timeout属性，如果你把它设置为24小时，则很难相信24小时之后用户的Session还在。Session是否存在，不仅仅依赖于Timeout属性，以下的情况都可能引起Session丢失（所谓丢失就是在超时以前原来的Session无效）。

·      bin目录中的文件被改写。asp.net有一种机制，为了保证dll重新编译之后，系统正常运行，它会重新启动一次网站进程，这时就会导致 Session丢失，所以如果有access数据库位于bin目录，或者有其他文件被系统改写，就会导致Session丢失。

·      SessionID丢失或者无效。如果你在URL中存储SessionID，但是使用了绝对地址重定向网站导致URL中的SessionID丢失，那么原来的Session将失效。如果你在Cookie中存储SessionID，那么客户端禁用Cookie或者Cookie达到了IE中Cookie数量的限制（每个域20个），那么Session将无效。

·      如果使用InProc的Session，那么IIS重启将会丢失Session。同理，如果使用StateServer的Session，服务器重新启动Session也会丢失。

一般来说，如果在IIS中存储Session而且Session的Timeout设置得比较长，再加上Session中存储大量的数据，非常容易发生Session丢失的问题。

最后， Session的安全性怎么样呢？我们知道，Session中只有SessionID是存储在客户端的，并且在页面每次提交的过程中加入HTTP头发送给服务器。SessionID只是一个识别符，没有任何内容，真正的内容是存储在服务器上的。总的来说安全性还是可以的，不过笔者建议你不要使用 cookieless和SqlServer模式的Session。把SessionID暴露在URL中，把内容存储在数据库中可能会发生攻击隐患。

12.3.7  遍历与销毁Session

Session虽然很方便，但是要用好Session还需要自己不断实践，根据自己网站的特点灵活使用各种模式的Session。关于使用程序访问Session，笔者还想补充两点。

·      如何遍历当前的Session集合。

System.Collections.IEnumerator SessionEnum = Session.Keys.GetEnumerator();

while (SessionEnum.MoveNext())

{

    Response.Write(Session[SessionEnum.Current.ToString()].ToString() + "<br/>");

}

对于我们这个例子，输出和图12-1一样。如果你仅仅为了监视Session，也可以通过trace来获得详细信息。在Web.config的system.Web节点中添加：

<trace enabled="true"  pageOutput="true"/>

打开页面后单击“写入Session”按钮，页面显示如图12-11所示。

图12-11  使用trace观察会话状态

·      如何立刻让Session失效。比如用户退出系统后，Session中保存的所有数据全部失效，可以使用以下代码来让Session失效。

Session.Abandon();

12.3.8  Session的常见问题与总结

Session的基本知识就介绍到这里，现在再回头看第一节中的几个问题，你是否都能回答了呢？为了强化大家的概念，笔者就三种模式的Session进行了一个比较（假设都使用Cookie来存储SessionID）。

表12.1  三种模式的Session比较

	InProc	StateServer	SQLServer
存储物理位置	IIS进程（内存）	Windows服务进程（内存）	SQLServer数据库（磁盘）
存储类型限制	无限制	可以序列化的类型	可以序列化的类型
存储大小限制	无限制
使用范围	当前请求上下文，对于每个用户独立
生命周期	第一次访问网站的时候创建Session超时后销毁
优点	性能比较高	Session不依赖Web服务器，不容易丢失
缺点	容易丢失	序列化与反序列化消耗CPU资源	序列化与反序列化消耗CPU资源，从磁盘读取Session比较慢
使用原则	不要存放大量数据

在使用Session的过程中你可能还会遇到很多奇怪的问题，结束本节之前笔者列出了几条常见的FAQ，供大家参考：

·      为什么每次请求的SessionID都不相同？

n  可能是没有在Session里面保存任何信息引起的，即程序中任何地方都没有使用Session。只有在Session中保存了内容后，Session才会和浏览器进行关联，此时的SessionID将不会再变化。

·      为什么当我设置cookieless为true后，在重定向的时候会丢失Session？

n  当使用cookieless时，你必须使用相对路径替换程序中的绝对路径，如果使用绝对路径，ASP.NET将无法在URL中保存SessionID。

·      有办法知道应用程序的Session在运行时占用了多少内存吗？

n  没有办法，你可以通过观察IIS进程（InProc模式）或者aspnet_state进程（StateServer模式）大致估计。

·      有没有可能知道整个网站使用Session的用户列表？

n  对于InProc模式和StateServer模式很难，对于SqlServer模式你可以查询存储Session的表进行尝试。

·      当页面中设了frameset，发现在每个frame中显示页面的SessionID在第一次请求时都不相同，为什么？

n  原因是你的frameset是放在一个HTML页面上而不是ASPX页面。在一般情况下，如果frameset是aspx页面，当你请求页面时，它首先将请求发送到Web服务器，此时已经获得了SessionID，接着浏览器会分别请求Frame中的其他页面，这样所有页面的SessionID就是一样的，就是FrameSet页面的SessionID。然而如果你使用HTML页面做FrameSet页面，第一个请求将是HTML页面，当该页面从服务器上返回时并没有任何Session产生，接着浏览器会请求Frame里面的页面，这样，这些页面都会产生自己的SessionID，所以在这种情况下就可能出现这种问题。当你重新刷新页面时，SessionID就会一样，并且是最后一个请求页面的SessionID。

exec sp_configure 'show advanced options',1
reconfigure
exec sp_configure 'Ad Hoc Distributed Queries',1
reconfigure

　　如果用户对数据库操作的效率比较关注，那么还有3组比较重要的，也是常用的JDBC函数，分别是：

　　(1)事务处理函数：setAutoCommit/commit/rollback

　　(2)批处理函数：addBatch/execBatch

　　(3)语句预处理函数：prepareStatement

　　对于大多数开发人员，只需要知道其用法含义即可，深层次的探索和分析可能需要另外的篇幅来说明，因此作者在此不再赘述。

　　实际上，上述基本函数的定义，大部分都是对JDK中JDBC函数的封装，读者也可以通过JDBC的文档进行相关的查阅。关键代码参见全文末尾附录部分。

　　2.数据库表定义

　　作为试用，作者并没有定义很复杂的数据库表，以下是测试用数据表结构：

create table user_info( 　　ui_id varchar(64), 　　ui_passwd varchar(64), 　　ui_real_name varchar(64), primary key(ui_id));

　　3.试用思路

　　比较简单，就是通过上述不同类型的JDBC驱动来连接各种数据库平台，然后向已经初始化的数据表插入10000条记录，再逐条读取，并记录其各个步骤的执行耗费。

　　四、试用过程

　　1.平台选择

　　作者选择了MS Windows XP和Solaris两种平台。其中只有MySQL，JavaDB和Oracle(连接远程服务器)既可在Windows平台进行了测试，也可在Solaris平台下进行了测试。两个系统下的测试代码和框架完全相同。

　　2.使用JDBC驱动连接数据库

　　(1)Access数据库

　　通过JDBC驱动连接Access数据库最常用的是采用建立ODBC数据源(DSN)的方式进行，但是本测试中采用的是通过数据库连接字符串避开了手工建立DSN的部分。以下是关键代码：

　

final String connectStr = 　　“jdbc:odbc:driver={Microsoft Access Driver (*.mdb)};DBQ=./TestDB.mdb”; 　　…… 　　if( (conn = FoolDB.openDB(connectStr, null, null)) == null)

　　用过ADO的读者可能一眼就看出来了，上述的连接字符串中的内容和ADO很相似。事实上，作者就是为了避开建立DNS而尝试套用了ADO的连接字符串，结果尝试通过了!

　　(2)SQL Server数据库

　　需要说明的，对于SQL Server的测试没有采用Microsoft提供的SQL Server专用的JDBC驱动，还是通过借鉴ADO的连接字符串形式，沿用了JDK自带的JdbcOdbc驱动。

final String connectStr = 　　“jdbc:odbc:Driver={SQL Server};Server=.;Database=master;UID=sa;PWD=121fs”; 　　…… 　　if( (conn = FoolDB.openDB(connectStr, null, null)) == null)

　　注意：用户名和密码已经包含到连接字符串中。

　　(3)MySQL数据库

　　众所周知，MySQL数据库既可以在Windows可以在Solaris平台运行，而且执行效率也深得业界的好评。本试例中连接MySQL使用的是MySQL专用驱动(在第一部分已经详述，在MySQL官方网页有很多的支持文档)，以下是关键代码：

final String connectStr = “jdbc:mysql://localhost/phome”; 　　final String userName = “root”; // 　　final String passwd = ““; 　　…… 　　if( (conn = FoolDB.openDB(connectStr, userName, passwd)) == null)

　　在本地连接时，主机名可以使用“localhost”，但如果连接远程主机时，必须换成该远程主机的IP，而phome是MySQL数据库名称。

　　(4)Oracle数据库

　　Oracle提供了thin和oci两种类型的驱动，本测试中使用thin类型JDBC驱动。

final String connectStr = “jdbc:oracle:thin:@WBS:1521/oracle088”; 　　final String userName = “test”; 　　final String passwd = “test”;

　　其中“WBS:1521/oracle088”为Oracle服务器的SID。

　　(5)Java DB

　　值得一提的，Java DB是由Apache Software Foundation主要参与开发的一个数据库(DB)项目，SUN在JDK1.6.0中将其进行了绑定，它是一款名副其实的纯Java代码开发的数据库平台。可以支持Server/Client也可以支持嵌入式运行模式，本实例中主要采用了嵌入式模式(Embedded)进行操作：

final String connectStr = “jdbc:derby:FoolDB”; 　　…… 　　if( (conn = FoolDB.openDB(connectStr, null, null)) == null)

　　其中FoolDB是在初始化过程中，使用连接字符串“jdbc:derby:FoolDB;create=true”进行创建的。创建的结果是：在当前目录中创建一个名为FoolDB的目录，该目录又中包含log，seg0和tmp这3个文件夹，而数据库内容以多文件的方式存放于seg0目录中。

　　注意：数据库一旦创建之后，就无需再次创建了。

　　3.设置数据库事务方式

　　当数据库连接成功之后，需要设定连接的事务方式(前提是该数据库平台支持事务处理)为非自动提交，因为JDBC函数默认为自动提交。

　　提交过于频繁，就会使数据库操作的效率较低。特别是对于Oracle这种绝对支持事务处理的数据平台而言，设置是否自动提交对系统的效率将有很大的影响。

　　同样一个考虑效率的操作，循环地执行操作语句(Insert，Update)也会增加很多不必要地开销。试例中采用了批量处理的方式，通过这种方式将要进行的操作先进行汇总，再批量提交执行。这样就可以获得较高的执行效率。

//Insert records 　　for(int i = 0; i < RECORD_COUNT; ++i) 　　{ 　　//Add each operation to batch 　　if(FoolDB.addBatch(execStat, “insert into user_info values('guest” 　　+ Integer.toString(i + 1) 　　+ “', '666666', '我是中国人')”) == false) 　　…… 　　FoolDB.execBatch(execStat); //Execute batch operations 　　FoolDB.commit(conn); 　　FoolDB.setAutoCommit(conn, true);

　　这种批处理的方式，可以视同预处理，通过统合批量的操作来减少与数据库的交互频率，也减少数据库访问IO设备的频率，从而也可获得较高的效率。

　　5.使用行游标读取记录字段

　　记录插入完毕之后，通过执行查询语句来获取数据集。然后再通过简化函数moveNext来逐行读取结果集的记录行：

//Select from table 　　String sql = "select * from user_info"; 　　if( (queryRS = FoolDB.openQuery(queryStat, sql)) == null) 　　{ 　　… 　　} 　　… 　　while(FoolDB.moveNext(queryRS) == true) 　　{ 　　//Field ui_id, text(64) type 　　FoolDB.getFieldByName(queryRS, “ui_id”); 　　//Field ui_passwd, text(64) type 　　FoolDB.getFieldByName(queryRS, “ui_passwd”); 　　//Field ui_real_name, text(64) type 　　FoolDB.getFieldByName(queryRS, “ui_real_name”); 　　}

　　实际上，moveNext的函数名也来源于ADO(在作者看来，JDBC和ADO的应用方式是相同的)。

　　6.关闭数据库

　　这里主要对以嵌入式模式运行的JavaDB的关闭进行说明，其他数据库的关闭，直接采用简化后的关闭函数(closeDB)即可。

　　在嵌入式模式，应用程序退出时就必须关闭数据库。但是如果应用程序关闭数据库失败，当JVM退出时不会对该未被关闭的连接进行检查，这样就占用了数据库的连接资源，就会影响后续的连接执行效率。所以Apache Derby的建议是采用URL的方式显示地关闭数据库。以下是关键代码：

FoolDB.closeDB(conn); //Close connection 　　if(framework.equals("embedded") == true) //If in embedded mode 　　{ 　　//Use URL to shutdown Derby 　　if(FoolDB.openDB("jdbc:derby:;shutdown=true", null, null) == null) 　　{ 　　//If shutdown failure means that Derby already shutdown 　　isShutdownOk = true; 　　} 　　if (isShutdownOk == false) //Not shutdown normally 　　{ 　　System.out.println("Derby shutdown NG."); 　　} 　　}

　　注意：关闭和判断Derby数据库是否正常关闭的连接字符串中是不包含数据库名的。

　　以上的操作中，在各个步骤之间添加了时间戳，以此来记录各个数据库平台的执行耗费。

　　五、结果及分析

　　在对试用结果进行评价之前，读者需要考虑各款数据库平台的特点，而不能简单地从执行时间的长短来进行判断，以下是笔者根据开发经验总结出的需要注意的地方：

　　(1)要保证JDBC驱动和数据库平台的连接是无缝的。例如Oracle和JavaDB数据库本身就是由Java开发，其JDBC驱动和数据库平台的连接可以做到完全无缝，这样可以充分体现出该款数据库平台的特性。反之，Access和SQL Server与对应的JdbcOdbc驱动之间的耦合可能就不如与ADO驱动那么吻合，那么这些数据平台的很多特性就无法通过这些JDBC驱动得以体现。之前我们也提到，Microsoft专门有提供MS SQL Server的JDBC驱动，数据库与这种“对口”的JDBC驱动的耦合肯定要超过JdbcOdbc这种通用型的驱动。

　　(2)数据库平台要有良好的可移植性。换句话说就是数据库跨操作系统的性能。在这些方面Oracle，MySQL和JavaDB就要比Access和SQL Server有明显优势，它们不仅可以支持Windows平台而且也支持Solaris和Linux平台。而且数据库平台的可移植很大程度也决定了应用系统的可移植性。

　　(3)数据库平台要支持应用的多样化(需求弹性)。数据库平台应该不仅可以对应传统的C/S，B/S模式，而且还可以扩展为三层的，甚至是多层的模式，或者支持嵌入式系统的应用。显而易见，本身使用Java开发的Oracle和JavaDB在这些方面就具有得天独厚的优势。而且JavaDB还支持嵌入式应用，这样以来数据库的应用空间就更为广阔了。

　　所以基于以上几点的考虑，我们就可以得出初步的意向：

　　(1)对于一般的中小型的C/S和B/S架构，MySQL可以说是我们当前首选。它在跨平台和执行效率方面表现得相当的出色。

　　(2)对于那些对系统构架弹性要求比较高的系统，可以选择Oracle平台，并结合EJB规范进行搭建系统构架无疑将是很好的选择。

　　(3)选用JavaDB进行嵌入式平台开发似乎是不错的主意。由于现在很多嵌入式设备中都嵌入了Java内核，JavaDB也就可以得以应用了，嵌入式设备与其他系统共享数据的接口就变得及其简单。

　　(4)如果只在Windows平台进行开发的中小型系统，用Access或者SQL Server平台也不妨是一种简单快捷的途径。

　　六、结束语

　　通过前两部分的说明，相信大家对JDBC的使用应该有相当部分的了解和收获。即使作为初学者，通过简化后的JDBC函数和固定的试用方式，就可以实现通过JSP页面，Java Applet或者是Java Application等程序来访问各种类型的数据库平台了。即使是在本文中没有提到的其他数据库平台，例如：IBM的DB2，Solaris 10中绑定的PostgreSQL数据库。

　　尤其的，对于中高级技术人员而言，也可以通过这几种热门的数据库平台在不同操作系统下的使用案例得到一定的参考。

　　其中，特别是介绍了对嵌入式数据库的使用，相信也一定开阔了大家的视野和应用范围，毕竟嵌入式系统的应用在目前也是如火如荼。在后续的实际开发中笔者会将更多的心得体会和大家一起分享。

　　1.主要FoolDB函数参考

//Get a conn to special database. 　　public static Connection openDB(final String url, final String user, final String passwd) 　　{ 　　try 　　{ 　　return (DriverManager.getConnection(url, user, passwd) ); 　　} 　　catch (SQLException CONNECT_FAILURE) 　　{ 　　… 　　} 　　} 　　//Get a statement object that can be used for query (read only) 　　public static Statement getQueryStat(final Connection conn) 　　{ 　　try 　　{ 　　return (conn.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, 　　ResultSet.CONCUR_READ_ONLY) ); 　　} 　　catch(SQLException CREATE_QUERY_STATEMENT) 　　{ 　　… 　　} 　　} 　　//Get a statement object that can be used for update (can write) 　　public static Statement getExecStat(final Connection conn) 　　{ 　　try 　　{ 　　return (conn.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, 　　ResultSet.CONCUR_UPDATABLE) ); 　　} 　　catch(SQLException CREATE_EXEC_STATEMENT) 　　{ 　　… 　　} 　　} 　　//Execute SQL statement, and get the result set. 　　public static ResultSet openQuery(final Statement stat, final String sql) 　　{ 　　try 　　{ 　　return (stat.executeQuery(sql) ); 　　} 　　catch(SQLException OPEN_QUERY) 　　{ 　　… 　　} 　　} 　　//Get the rows cout of result set. 　　//The result set type should be ResultSet type is TYPE_SCROLL_SENSITIVE. 　　public static int getRowsCount(ResultSet rs) 　　{ 　　try 　　{ 　　int rowsCount = 0; 　　//Backup current row no. 　　int rowNo = rs.getRow(); 　　//Locate last row 　　rs.last(); 　　//Get the rows count 　　rowsCount = rs.getRow(); 　　//Return back original row 　　if(rowNo < 1) //before first row 　　{ 　　rs.beforeFirst(); 　　} 　　else // 　　{ 　　rs.absolute(rowNo); 　　} 　　return (rowsCount); 　　} 　　catch(SQLException GET_ROWS_COUNT_FAILURE) 　　{ 　　… 　　} 　　} 　　//Get the columns count of resut set. 　　public static int getColsCount(final ResultSet rs) 　　{ 　　try 　　{ 　　ResultSetMetaData rsmd = rs.getMetaData(); 　　return (rsmd.getColumnCount() ); 　　} 　　catch(SQLException GET_COLS_COUNT_FAILURE) 　　{ 　　… 　　} 　　} 　　//Get special column name. 　　//Note: The index of column base 1, but not 0. 　　public static String getColName(final ResultSet rs, final int colIndex) 　　{ 　　try 　　{ 　　ResultSetMetaData rsmd = rs.getMetaData(); 　　return (rsmd.getColumnName(colIndex) ); 　　} 　　catch(SQLException GET_COL_NAME_FAILURE) 　　{ 　　… 　　} 　　} 　　//Move the cursor of result set to next row 　　public static boolean moveNext(ResultSet rs) 　　{ 　　try 　　{ 　　return (rs.next() ); 　　} 　　catch(SQLException MOVE_NEXT_FAILURE) 　　{ 　　… 　　} 　　} 　　//Get the retValue of cell by special row number and column number 　　//The result set type should be ResultSet type is TYPE_SCROLL_SENSITIVE. 　　//Note: The index of row and column all base 1, but no 0. 　　public static Object getValueAt(ResultSet rs, final int rowIndex, final int colIndex) 　　{ 　　if( (rowIndex < 1) || (colIndex < 1) ) 　　{ 　　return (null); 　　} 　　try 　　{ 　　//Backup current row no. 　　int rowNo = rs.getRow(); 　　Object retValue = null; 　　//Locate to special row 　　rs.absolute(rowIndex); 　　//Get retValue 　　retValue = rs.getObject(colIndex); 　　//Return back origianl row 　　rs.absolute(rowNo); 　　return (retValue); 　　} 　　catch(SQLException GET_VALUE_FAILURE) 　　{ 　　… 　　} 　　} 　　//Get the retValue of cell by special row number and field name 　　//The result set type should be ResultSet type is TYPE_SCROLL_SENSITIVE. 　　//Note: The index of row and column all base 1, but no 0. 　　public static Object getFieldByName(ResultSet rs, final int rowIndex, final String fieldName) 　　{ 　　if( (rowIndex < 1) || (fieldName.equals("") == true) ) 　　{ 　　return (null); 　　} 　　try 　　{ 　　//Backup current row no. 　　int rowNo = rs.getRow(); 　　Object retValue = null; 　　//Locate to special row 　　rs.absolute(rowNo); 　　//Get retValue 　　retValue = rs.getObject(fieldName); 　　//Return back origianl row no. 　　rs.absolute(rowNo); 　　return (retValue); 　　} 　　catch(SQLException GET_FIELD_BY_NAME_FAILURE) 　　{ 　　… 　　} 　　} 　　//Get the retValue of cell within current row by special field name 　　//The result set type should be ResultSet type is TYPE_SCROLL_SENSITIVE. 　　//Note: The index of row and column all base 1, but no 0. 　　public static Object getFieldByName(final ResultSet rs, final String fieldName) 　　{ 　　if( (isBOF(rs) == true) || (isEOF(rs) == true) ) 　　{ 　　return (null); 　　} 　　try 　　{ 　　return (rs.getObject(fieldName) ); 　　} 　　catch(SQLException GET_FIELD_BY_NAME_FAILURE) 　　{ 　　… 　　} 　　} 　　//Get the retValue of cell within current row by special column index 　　//The result set type should be ResultSet type is TYPE_SCROLL_SENSITIVE. 　　//Note: The index of row and column all base 1, but no 0. 　　public static Object getFieldByIndex(final ResultSet rs, final int columnIndex) 　　{ 　　if( (columnIndex < 1) || (isBOF(rs) == true) || (isEOF(rs) == true) ) 　　{ 　　return (null); 　　} 　　try 　　{ 　　return (rs.getObject(columnIndex) ); 　　} 　　catch(SQLException GET_FIELD_BY_INDEX_FAILURE) 　　{ 　　… 　　} 　　}