事務是指對系統進行的一組操作，為了保證系統的完整性，事務需要具有ACID特性如下：
1. 原子性（Atomic）
一個事務包含多個操作，這些操作要么全部執行,要么全都不執行。實現事務的原子性，要支持回滾操作，在某個操作失敗后，回滾到事務執行之前的狀態。回滾實際上是一個比較高層抽象的概念，大多數DB在實現事務時，是在事務操作的數據快照上進行的（比如，MVCC），並不修改實際的數據，如果有錯並不會提交，所以很自然的支持回滾。而在其他支持簡單事務的系統中，不會在快照上更新，而直接操作實際數據。可以先預演一邊所有要執行的操作，如果失敗則這些操作不會被執行，通過這種方式很簡單的實現了原子性。
2. 一致性（Consistency）
一致性是指事務使得系統從一個一致的狀態轉換到另一個一致狀態。事務前后，數據庫的狀態都滿足所有的完整性約束。
3. 隔離性（Isolation）
並發事務之間互相影響的程度，比如一個事務會不會讀取到另一個未提交的事務修改的數據。在事務並發操作時，可能出現的問題有：
<一>臟讀：事務A修改了一個數據，但未提交，事務B讀到了事務A未提交的更新結果，如果事務A提交失敗，事務B讀到的就是臟數據。事務A：張三妻子給張三轉賬100元。事務B：張三查詢余額。事務A轉賬后（還未提交），事務B查詢多了100元。事務A由於某種問題，比如超時，進行回滾。事務B查詢到的數據是假數據。臟讀本質上是讀寫操作的沖突，解決辦法是寫完之后再讀。
<二>幻讀：A事務讀取了B事務已經提交的新增數據。注意和不可重復讀的區別，這里是新增，不可重復讀是更改（或刪除）。這兩種情況對策是不一樣的，對於不可重復讀，只需要采取行級鎖防止該記錄數據被更改或刪除，然而對於幻讀必須加表級鎖，防止在這個表中新增一條數據。一個事務兩次讀取一個范圍的記錄，兩次讀取的記錄數不一致。事務A：張三妻子兩次查詢張三有幾張銀行卡。事務B：張三新辦一張銀行卡。事務A第一次查詢銀行卡數的時候，張三還沒有新辦銀行卡，第二次查詢銀行卡數的時候，張三已經新辦了一張銀行卡，導致兩次讀取的銀行卡數不一樣。幻象讀本質上是讀寫操作的沖突，解決辦法是讀完再寫。
<三>不可重復讀：A事務讀取了B事務已經提交的更改（或刪除）數據。比如A事務第一次讀取數據，然后B事務更改該數據並提交，A事務再次讀取數據，兩次讀取的數據不一樣。在不可重復讀出現的原因就是事務並發修改記錄，要避免這種情況，最簡單的方法就是對要修改的記錄加鎖，這回導致鎖競爭加劇，影響性能。另一種方法是通過MVCC可以在無鎖的情況下，避免不可重復讀。一個事務兩次讀取同一個數據，兩次讀取的數據不一致。事務A：張三妻子給張三轉賬100元。事務B：張三兩次查詢余額。事務B第一次查詢余額，事務A還沒有轉賬，第二次查詢余額，事務A已經轉賬了，導致一個事務中，兩次讀取同一個數據，讀取的數據不一致。不可重復讀本質上是讀寫操作的沖突，解決辦法是讀完再寫。
<四>第一類丟失更新:A事務撤銷時，把已提交的B事務的數據覆蓋掉。
<五>第二類丟失更新:A事務提交時，把已提交的B事務的數據覆蓋掉。<三>的特例
事務的隔離級別從低到高有：
Read Uncommitted：最低的隔離級別，什么都不需要做，一個事務可以讀到另一個事務未提交的結果。所有的並發事務問題都會發生。
Read Committed：只有在事務提交后，其更新結果才會被其他事務看見。解決臟讀問題。
Repeated Read：在一個事務中，對於同一份數據的讀取結果總是相同的，無論是否有其他事務對這份數據進行操作，以及這個事務是否提交。可以解決臟讀、不可重復讀。
Serialization：事務串行化執行，隔離級別最高，犧牲了系統的並發性。可以解決並發事務的所有問題。通常，在工程實踐中，為了性能的考慮會對隔離性進行折中。
4. 持久性（Durability）事務提交后，對系統的影響是永久的
*********************************分頁符*************************************
事務隔離級別：
為了解決數據庫事務並發運行時的各種問題,數據庫系統提供四種事務隔離級別：
1. Serializable 串行化 2. Repeatable Read 可重復讀
3. Read Commited 可讀已提交4. Read Uncommited 可讀未提交
並發控制：
1.數據庫系統采用不同的鎖類型來實現以上四種隔離級別，具體的實現過程對用戶是透明的。用戶應該關心的是如何選擇合適的隔離級別。
2.對於多數應用程序，可以優先考慮把數據庫系統的隔離級別設為Read Committed，它能夠避免臟讀，而且具有較好的並發性能。
3.每個數據庫連接都有一個全局變量@@tx_isolation，表示當前的事務隔離級別。JDBC數據庫連接使用數據庫系統默認的隔離級別。
4.在Hibernate配置文件中可以顯示地設置隔離級別。每一種隔離級別對應一個正整數。
5.需要注意的是，在受管理環境中，如果Hibernate使用的數據庫連接來自於應用服務器提供的數據源，Hibernate不會改變這些連接的事務隔離級別。在這種情況下，應該通過修改應用服務器的數據源配置來修改隔離級別。
6.當數據庫系統采用Red Committed隔離級別時，會導致不可重復讀和第二類丟失更新的並發問題。可以在應用程序中采用悲觀鎖或樂觀鎖來避免這類問題。
悲觀鎖
正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度，因此，在整個數據處理過程中，將數據處於鎖定狀態。悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）。
一個典型的依賴數據庫的悲觀鎖調用：select * from account where name=”Erica” for update這條 sql 語句鎖定了 account 表中所有符合檢索條件（ name=”Erica” ）的記錄。本次事務提交之前（事務提交時會釋放事務過程中的鎖），外界無法修改這些記錄。悲觀鎖，也是基於數據庫的鎖機制實現。
在Hibernate使用悲觀鎖十分容易，但實際應用中悲觀鎖是很少被使用的，因為它每次發送的SQL語句都會加上"for update"用於告訴數據庫鎖定相關數據，限制了並發性.
樂觀鎖
相對悲觀鎖而言，樂觀鎖機制采取了更加寬松的加鎖機制。悲觀鎖大多數情況下依靠數據庫的鎖機制實現，以保證操作最大程度的獨占性。但隨之而來的就是數據庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於數據版本（Version）記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基於數據庫表的版本解決方案中，一般是通過為數據庫表增加一個"version"字段來實現。
樂觀鎖的工作原理：讀取出數據時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於數據庫表當前版本號，則予以更新，否則認為是過期數據。
Hibernate為樂觀鎖提供了3中實現：
1. 基於version Hibernate中通過版本號檢查來實現后更新為主，這也是Hibernate推薦的方式。在數據庫表中加入一個version(版本)字段，在讀取數據時連同版本號一起讀取，並在更新數據時比較版本號與數據庫表中的版本號，如果等於數據庫表中的版本號則予以更新，並遞增版本號，如果小於數據庫表中的版本號就拋出異常
2. 基於timestamp
*********************************分頁符*************************************
窗體頂端
在數據庫訪問時。如果處理並發訪問的問題
或者當一個操作員對一個對象作讀操作時。另一個操作員對此對象作寫操作的時候
如何避免死鎖發生窗體底端
/********** 加鎖 ***************
設table1(A,B,C)
A B C
a1 b1 c1
a2 b2 c2
a3 b3 c3
1）排它鎖
新建兩個連接
在第一個連接中執行以下語句
begin tran
update table1
set A='aa'
where B='b2'
waitfor delay '00:00:30' --等待30秒
commit tran
在第二個連接中執行以下語句
begin tran
select * from table1
where B='b2'
commit tran
若同時執行上述兩個語句，則select查詢必須等待update執行完畢才能執行即要等待30秒
2）共享鎖
在第一個連接中執行以下語句
begin tran
select * from table1 holdlock -holdlock人為加鎖
where B='b2'
waitfor delay '00:00:30' --等待30秒
commit tran
在第二個連接中執行以下語句
begin tran
select A,C from table1
where B='b2'
update table1
set A='aa'
where B='b2'
commit tran
若同時執行上述兩個語句，則第二個連接中的select查詢可以執行
而update必須等待第一個連接中的共享鎖結束后才能執行 即要等待30秒
3）死鎖
增設table2(D,E)
D E
d1 e1
d2 e2
在第一個連接中執行以下語句
begin tran
update table1
set A='aa'
where B='b2'
waitfor delay '00:00:30'
update table2
set D='d5'
where E='e1'
commit tran
在第二個連接中執行以下語句
begin tran
update table2
set D='d5'
where E='e1'
waitfor delay '00:00:10'
update table1
set A='aa'
where B='b2'
commit tran
同時執行，系統會檢測出死鎖，並中止進程
--------------------------------------------------------------
SET IMPLICIT_TRANSACTIONS ON --用戶每次必須顯式提交或回滾。否則當用戶斷開連接時,
--事務及其所包含的所有數據更改將回滾
SET IMPLICIT_TRANSACTIONS OFF --自動提交模式。在自動提交模式下，如果各個語句成功
--完成則提交。
1:如上
2: 如何鎖一個表的某一行
A 連接中執行
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
begin tran
select * from tablename with (rowlock) where id=3
waitfor delay '00:00:05'
commit tran
B連接中如果執行
update tablename set colname='10' where id=3 --則要等待5秒
update tablename set colname='10' where id<>3 --可立即執行
2 鎖定數據庫的一個表
SELECT * FROM table WITH (HOLDLOCK)
注意: 鎖定數據庫的一個表的區別
SELECT * FROM table WITH (HOLDLOCK)
其他事務可以讀取表，但不能更新刪除
SELECT * FROM table WITH (TABLOCKX)
其他事務不能讀取表,更新和刪除
SELECT 語句中“加鎖選項”的功能說明
SQL Server提供了強大而完備的鎖機制來幫助實現數據庫系統的並發性和高性能。用戶既能使用SQL Server的缺省設置也可以在select 語句中使用“加鎖選項”來實現預期的效果。 本文介紹了SELECT語句中的各項“加鎖選項”以及相應的功能說明。
功能說明：
NOLOCK（不加鎖）
此選項被選中時，SQL Server 在讀取或修改數據時不加任何鎖。 在這種情況下，用戶有可能讀取到未完成事務（Uncommited Transaction）或回滾(Roll Back)中的數據, 即所謂的“臟數據”。
HOLDLOCK（保持鎖）
此選項被選中時，SQL Server 會將此共享鎖保持至整個事務結束，而不會在途中釋放。
UPDLOCK（修改鎖）
此選項被選中時，SQL Server 在讀取數據時使用修改鎖來代替共享鎖，並將此鎖保持至整個事務或命令結束。使用此選項能夠保證多個進程能同時讀取數據但只有該進程能修改數據。
TABLOCK（表鎖）
此選項被選中時，SQL Server 將在整個表上置共享鎖直至該命令結束。 這個選項保證其他進程只能讀取而不能修改數據。
PAGLOCK（頁鎖）
此選項為默認選項， 當被選中時，SQL Server 使用共享頁鎖。
TABLOCKX（排它表鎖）
此選項被選中時，SQL Server 將在整個表上置排它鎖直至該命令或事務結束。這將防止其他進程讀取或修改表中的數據。
--或者自己加鎖(控制更靈活)
--鎖定記錄,只允許單用戶修改的例子:
--創建測試環境
--創建測試表--部門表
create table 部門(departmentid int,name varchar(10))
--記錄鎖定表
create table lock(departmentid int,dt datetime)
go
--因為函數中不可以用getdate,所以用個視圖,得到當前時間
create view v_getdate as select dt=getdate()
go
--創建自定義函數,判斷記錄是否鎖定
create function f_chk(@departmentid int)
returns bit
as
begin
declare @re bit,@dt datetime
select @dt=dt from v_getdate
if exists(select 1 from lock where departmentid=@departmentid
and datediff(ss,dt,@dt)<5)
set @re=1
else
set @re=0
return(@re)
end
go
--數據處理測試
if dbo.f_chk(3)=1
print '記錄被鎖定'
else
begin
--也可以是查詢
begin tran
insert into lock values(3,getdate())
update 部門 set name='A' where departmentid=3
delete from lock where departmentid=3
commit tran
end
--刪除測試環境
drop table 部門
drop view v_getdate
drop function f_chk
如果是死鎖可以查一下：
1：sp_who 或 sp_who2
2: Select * from sysprocesses where blocked <> 0
3: 企業管理器－＞服務器－＞管理工具－＞活動－＞當前活動 然后把他kill掉。。。
進程信息中，如果發現旁邊有一個鎖狀的圖標，就表明這個進程是死鎖，kill掉
4：SQL事件探查器，監控一下,看主要是那些處理引起的死鎖.然后做相應的處理.
用事件探查器new一個trace，監視一下造成你sqlserver停頓的情況。。。
最好的辦法還是檢查一下引起鎖的原因，一般是由你的代碼引起的。
經過根蹤調試。我發現問題如下：
1。當一個操作對一張表進行讀操作的時候。這時如果另一個表進行讀操作沒有問題。如果
另一個操作對這個表進行寫操作的時候。就會出現這樣的情況。在單擊保存時。會持續等。
只有另一個讀操作的程序。退出讀表的界面。這個就會保存成功。
2。如果把同樣的環境改到我的筆記本上沒有這個問題。如果再放到IBM服務器上就會出現上述所講的問題。
現有疑問如下：
1。為何筆記本做服務（P41。8CPU。256M）沒有問題。面用IBM做服務器有問題？
2。如果我把SQLCA。AUTOCOMMIT=FALSE改為SQLCA。AUTOCOMMIT=TRUE。這個問題就不存在了。但是我想這只是從表面上解決了這個問題。沒有從根上解決這個問題。
3。如果是多個工作站。一台用SQLCA。AUTOCOMMIT=TRUE，另一台AUTOCOMMIT=FALSE會有問題嗎。？如果我想進行ROLLBACK操作會有問題嗎？
4。如果在同一個網段上有兩個SQLSERVER2000服務器會有影響嗎？