首先是我所作的B/S軟件需要多種數(shù)據(jù)庫的支持,其中就包括Access數(shù)據(jù)庫。而為了達到快的速度,必須把access的連接放入數(shù)據(jù)庫連接池,所以我專門給access做了個數(shù)據(jù)庫連接池。
問題出現(xiàn)了:“就是用access連接池的時候,有的時候會出現(xiàn)修改過的數(shù)據(jù)不能及時的反應(yīng)到界面上來。”
剛開始我以為是我的access連接池寫的有問題,于是是大找特找就是找不到原因,后來我干脆不用池,直接自己new一個全局連接放在靜態(tài)變量里看一下會不會有問題,結(jié)果顯示完全沒有問題。
接著我又new 了兩個連接放在靜態(tài)變量里 conn1 和 conn2 , 然后讓conn1做了一個update數(shù)據(jù)操作,conn2又立馬獲取update的值,結(jié)果顯示 獲取的數(shù)據(jù)還是update前的數(shù)據(jù), 然后過3到5秒 再讓conn2去獲取update的值 才能看到已經(jīng)修改了。
于是我得出這樣的結(jié)論,access數(shù)據(jù)庫的多個連接情況下,其中某一個連接進行了修改操作需要過3到4秒才能反映到其他連接里來.如果這個結(jié)論被確定那就是說access無法實現(xiàn)傳統(tǒng)上的數(shù)據(jù)庫連接池。
于是我想會不會是我的數(shù)據(jù)庫操作代碼有問題,于是我干脆用兩臺電腦做測試,分別在兩臺電腦上用office打開同一個access數(shù)據(jù)庫,然后在其中一臺上修改了某個數(shù)據(jù),另外一臺上立馬打開改數(shù)據(jù),結(jié)果顯示 數(shù)據(jù)還是沒有更新。 靠。從目前來看我上面的結(jié)論是符合實際的。
如果真的這個結(jié)論被坐實的話,就像我上面說的,“access無法實現(xiàn) 傳統(tǒng)上的 數(shù)據(jù)庫連接池”。那麻煩就大了,因為其他數(shù)據(jù)庫連接池,如:sqlserver,是可以用的,而access不能用,那么可能需要更多的代碼區(qū)分開來編寫。
于是我又想,會不會是使用access連接的時候有沒有什么特殊的屬性(或者說方式),才能保證多個access連接能及時的反應(yīng)信息。
這里付上操作數(shù)據(jù)庫的代碼:
說明:test.mdb中一個表,test 表,中間有兩個自段id 和num 都是數(shù)字。記錄就一條:id=1 num=1
protected void LinkButton11_Click(object sender, EventArgs e)
{
String connStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + Server.MapPath("/test.mdb") + ";Persist Security Info=True;";
String selectSql = "select [num] from [test] where [id]=1";
String updateSql = "Update [test] set [num]=[num]+1 where [id]=1";
OleDbConnection connForUpdate = new OleDbConnection(connStr);
OleDbConnection connForSelect = new OleDbConnection(connStr);
OleDbCommand cmd;
Object resultValue;
try
{
connForUpdate.Open();
connForSelect.Open();
//修改前提取
cmd = new OleDbCommand(selectSql, connForSelect);
resultValue = cmd.ExecuteScalar();
Response.Write("修改前:" + resultValue);
Response.Write("<br/>");
resultValue = null;
//執(zhí)行修改
cmd = new OleDbCommand(updateSql, connForUpdate);
cmd.ExecuteNonQuery();
//修改后提取
cmd = new OleDbCommand(selectSql, connForSelect);
resultValue = cmd.ExecuteScalar();
Response.Write("修改后:" + resultValue);
}
finally
{
connForSelect.Close();
connForUpdate.Close();
}
}
此代碼的結(jié)果是:
修改前:6
修改后:6
最終結(jié)論是,Access確實不能很好的實現(xiàn)連接池。 沒法子,只能是變相的解決問題了。
我這里給出Access操作的幾個可以提高速度方法:
1.讓某些只是提取操作的單步業(yè)務(wù)使用同一個鏈接, 該連接因為都是單步提取數(shù)據(jù),所以“不是即時性”的數(shù)據(jù)問題不大,如:獲取點擊數(shù)、查詢等等都使用同一個連接,此conn保持狀態(tài)不要關(guān)閉。
2.如果是非單步的業(yè)務(wù)就要使用完了連接及時關(guān)閉,不然會出現(xiàn)看不到剛剛更新過的數(shù)據(jù),如:新增一條記錄,新增完后要顯示此記錄的結(jié)果,由于是兩張頁面所以保證第一張頁面的conn關(guān)閉了,第二張頁面new出來,就沒有問題。
3.這里可以思考這樣的連接池,在conn返回到連接池的時候會把conn和session綁定起來,在需要獲取一個連接的時候,先要判斷所有和session綁定的conn,綁定時間在5秒前的就取消綁定,并把連接放回到freelist列表里,然后是根據(jù)傳進來sessionID,如果在和session綁定的conn集合中能夠找到相同的id那么就再次使用這個conn。如此這般便也可以算是一個連接池。
新聞熱點
疑難解答