1.悲观锁：
它指的是Ҏ据被外界修改持保守态度。假定Q何时d取数据时Q都可能有另一个客户也正在存取同一W数据，Z保持数据被操作的一致性，于是Ҏ据采取了数据?/strong>层次?a style="width: 20px; height: 20px; text-indent: 20px; background-repeat: no-repeat; background-image: url(/CuteSoft_Client/CuteEditor/Load.ashx?type=image&file=anchor.gif);" name="baidusnap0">锁定状态，依靠数据?/strong>提供的锁机制来实现?br />
Zjdbc实现?strong style="color: black; background-color: #a0ffff;">数据?/strong>加锁如下Q?br />
select * from account where name="Erica" for update.在更新的q程中，数据?/strong>处于加锁状态，M其他的针Ҏ条数据的操作都将被gq。本ơ事务提交后解锁?br />
而hibernate悲观锁的具体实现如下Q?br />
String sql="查询语句";
Query query=session.createQuery(sql);
query.setLockMode("对象"QLockModel.UPGRADE);
说到q里Q就提到了hiernate的加锁模式：
LockMode.NONE Q?无锁机制?br /> LockMode.WRITE QHibernate在Insert和Update记录的时候会自动获取?br /> LockMode.READ Q?Hibernate在读取记录的时候会自动获取?br />
q三U加锁模式是供hibernate内部使用的，?strong style="color: black; background-color: #a0ffff;">数据?/strong>加锁无关
LockMode.UPGRADEQ利?strong style="color: black; background-color: #a0ffff;">数据?/strong>的for update字句加锁?br />
在这里我们要注意的是Q只有在查询开始之前（也就是hiernate生成sql语句之前Q加锁，才会真正通过数据?/strong>的锁机制加锁处理。否则，数据已经通过不包含for updata子句的sql语句加蝲q来Q所谓的数据?/strong>加锁也就无从谈v?br />
但是Q从pȝ的性能上来考虑Q对于单机或系l而言Q这q不成问题，然而如果是在网l上的系l，同时间会有许多联机，假设有数以百计或上千甚至更多的ƈ发访问出玎ͼ我们该怎么办？如果{到数据?/strong>解锁我们再进行下面的操作Q我们浪费的资源是多？--q也导致了乐观锁的产生?br />
2.乐观锁：
乐观锁定Qoptimistic lockingQ则乐观的认料的存取很少发生同时存取的问题，因而不?strong style="color: black; background-color: #a0ffff;">数据?/strong>层次上的锁定Qؓ了维护正的数据Q乐?strong style="color: black; background-color: #ffff66;">锁定采用应用E序上的逻辑实现版本控制的方法?br />
例如若有两个客户端，A客户先读取了账户余额100元，之后B客户也读取了账户余额100元的数据QA客户提取?0元，?strong style="color: black; background-color: #a0ffff;">数据?/strong>作了变更Q此?strong style="color: black; background-color: #a0ffff;">数据?/strong>中的余额?0元，B客户也要提取30元，Ҏ其所取得的资料，100-30ؓ70余额Q若此时再对数据?/strong>q行变更Q最后的余额׃不正?br />
在不实行悲观锁定{略的情况下Q数据不一致的情况一但发生，有几个解决的ҎQ一U是先更Cؓ主，一U是后更新的ZQ比较复杂的是查发生变动的数据来实玎ͼ或是查所有属性来实现乐观锁定?br />
Hibernate 中透过版本h查来实现后更Cؓ主，q也是Hibernate所推荐的方式，?strong style="color: black; background-color: #a0ffff;">数据?/strong>中加入一个VERSON栏记录，在读取数据时q同版本号一同读取，q在更新数据旉增版本P然后比对版本号与数据?/strong>中的版本P如果大于数据?/strong>中的版本号则予以更新Q否则就回报错误?br />
以刚才的例子QA客户d账户余额1000元，q连带读取版本号?的话QB客户此时也读取̎号余?000元，版本号也?QA客户在领Ƒ账户余额?00Q此时将版本号加1Q版本号目前?Q?strong style="color: black; background-color: #a0ffff;">数据?/strong>中版本号?Q所以予以更斎ͼ更新数据?/strong>后，数据?/strong>此时余额?00Q版本号?QB客户领款后要变更数据?/strong>Q其版本号ؓ5Q但?strong style="color: black; background-color: #a0ffff;">数据?/strong>的版本号?Q此时不予更斎ͼB客户数据重新d数据?/strong>中新的数据ƈ重新q行业务程才变?strong style="color: black; background-color: #a0ffff;">数据?/strong>?br />
以Hibernate实现版本h?strong style="color: black; background-color: #ffff66;">锁定的话Q我们的对象中增加一个version属性，例如Q?br />
<public class Account {
private int version;
....
public void setVersion(int version) {
this.version = version;
}
public int getVersion() {
return version;
}
....
}
而在映像文g中，我们使用optimistic-lock属性设定version控制Q?lt;id>属性栏之后增加一?lt;version>标签Q如下：
<hibernate-mapping>
<class name="onlyfun.caterpillar.Account" talble="ACCOUNT"
optimistic-lock="version">
<id...../>
<version name="version" column="VERSION"/>
....
</class>
</hibernate-mapping>
讑֮好版本控制之后，在上例中如果B 客户试图更新数据Q将会引发StableObjectStateException例外Q我们可以捕捉这个例外，在处理中重新d数据?/strong>中的数据Q同时将 B客户目前的数据与数据?/strong>中的数据U出来Q让B客户有机会比对不一致的数据Q以军_要变更的部䆾Q或者您可以设计E式自动d新的资料Qƈ重复扣款业务程Q直到数据可以更Cؓ止，q一切可以在背景执行Q而不用让您的客户知道?br />
但是乐观锁也有不能解决的问题存在Q上面已l提到过乐观锁机制的实现往往Zpȝ中的数据存储逻辑Q在我们的系l中实现Q来自外部系l的用户余额更新不受我们pȝ的控Ӟ有可能造成非法数据被更新至数据?/strong>。因此我们在做电子商务的时候，一定要心的注意这存在的问题Q采用比较合理的逻辑验证Q避免数据执行错误?br />
也可以在使用Session的load()或是lock()时指?strong style="color: black; background-color: #ffff66;">锁定模式以进?strong style="color: black; background-color: #ffff66;">锁定?br />
如果数据?/strong>不支持所指定?strong style="color: black; background-color: #ffff66;">锁定模式QHibernate会选择一个合适的锁定替换Q而不是丢Z个例外?
]]>
悲观锁定 假定M时刻存取数据Ӟ都可能有另一个客户也正在存取同一W数据，因而对数据采取了数据库层次的锁定状态，在锁定的旉内其它的客户不能对资 料进行存取，对于单机或小pȝ而言Q这q不成问题，然而如果是在网l上的系l，同时间会有许多联机，如果每一ơ读取数据都造成锁定Q其后的存取就必须{? 待，q将造成效能上的问题Q造成后使用者的长时间等待?span lang="EN-US">
乐观锁定Qoptimistic lockingQ则乐观的认料的存取很少发生同时存取的问题，因而不作数据库层次上的锁定Qؓ了维护正的数据Q乐观锁定用应用程序上的逻辑实现版本控制的解冟?br /> 例如若有两个客户端，A客户先读取了账户余额1000元，之后B客户也读取了账户余额1000元的数据QA客户提取?00元，Ҏ据库作了变更Q此? 数据库中的余额ؓ500元，B客户也要提取300元，Ҏ其所取得的资料，1000-300ؓ700余额Q若此时再对数据库进行变_最后的余额׃? 正确?br /> 在不实行悲观锁定{略的情况下Q数据不一致的情况一但发生，有几个解决的ҎQ一U是先更Cؓ主，一U是后更新的ZQ比较复杂的是查发生变动的数据来实玎ͼ或是查所有属性来实现乐观锁定?br /> Hibernate中透过版本h查来实现后更Cؓ主，q也是Hibernate所推荐的方式，在数据库中加入一个VERSON栏记录，在读取数据时q? 同版本号一同读取，q在更新数据旉增版本P然后比对版本号与数据库中的版本号Q如果大于数据库中的版本号则予以更新Q否则就回报错误?br /> 以刚 才的例子QA客户d账户余额1000元，q连带读取版本号?的话QB客户此时也读取̎号余?000元，版本号也?QA客户在领Ƒ账户余额 ?00Q此时将版本号加1Q版本号目前?Q而数据库中版本号?Q所以予以更斎ͼ更新数据库后Q数据库此时余额?00Q版本号?QB客户领款后要 变更数据库，其版本号?Q但是数据库的版本号?Q此时不予更斎ͼB客户数据重新d数据库中新的数据q新进行业务流E才变更数据库?br /> 以Hibernate实现版本h刉定的话，我们的对象中增加一个version属性，例如Q?/span>
public class Account {
private int version;
....
public void setVersion(int version) {
this.version = version;
}
public int getVersion() {
return version;
}
....
}
而在映像文g中，我们使用optimistic-lock属性设定version控制Q?lt;id>属性栏之后增加一?lt;version>标签Q例如：
<hibernate-mapping>
<class name="onlyfun.caterpillar.Account" talble="ACCOUNT"
optimistic-lock="version">
<id...../>
<version name="version" column="VERSION"/>
....
</class>
</hibernate-mapping>
讑֮好版本控制之后，在上例中如果B
客户试图更新数据Q将会引发StableObjectStateException例外Q我们可以捕捉这个例外，在处理中重新d数据库中的数据，同时?
B客户目前的数据与数据库中的数据秀出来Q让B客户有机会比对不一致的数据Q以军_要变更的部䆾Q或者您可以设计E?
式自动读取新的资料，q复扣ƾ业务流E，直到数据可以更新为止Q这一切可以在背景执行Q而不用让您的客户知道?br />
悲观锁定在多个客L可能d同一W数据或同时更新一W数据的情况下，必须要有讉K控制的手D，防止同一个数据被修改而造成混ؕQ最单的手段是Ҏ据进行锁定，在自p行数据读取或更新{动作时Q锁定其它客L不能对同一W数据进行Q何的动作?span lang="EN-US">
悲观锁定QPessimistic LockingQ一如其名称所C，悲观的认定每ơ资料存取时Q其它的客户端也会存取同一W数据，因此对该W数据进行锁定，直到自己操作完成后解除锁定?/span>
悲观锁定通常透过pȝ或数据库本n的功能来实现Q依赖系l或数据库本w提供的锁定机制Q?span lang="EN-US">Hibernatex如此Q我们可以利用Query或Criteria的setLockMode()Ҏ来设定要锁定的表或列QrowQ及光定模式，锁定模式有以下的几个Q?/span>
- LockMode.WRITEQ在insert或update时进行锁定，Hibernate会在save()Ҏ时自动获得锁定?o:p>
- LockMode.UPGRADEQ利用SELECT … FOR UPDATEq行锁定?o:p>
- LockMode.UPGRADE_NOWAITQ利用SELECT … FOR UPDATE NOWAITq行锁定Q在Oracle环境下用?o:p>
- LockMode.READQ在d记录时Hibernate会自动获得锁定?o:p>
- LockMode.NONEQ没有锁定?o:p>
]]>