灰心锁
它指的是对数据被外界修改持守旧立场。假定任何时刻存取数据时，都大概有另一个客户也正在存取同一笔数据，为了保持数据被操纵的一致性，于是对数据采纳了数据库条理的锁定状态，依靠数据库提供的锁机制来实现。 基于jdbc实现的数据库加锁如下：
select * from account where name="Erica" for update
在更新的进程中，数据库处于加锁状态，任何其他的针对本条数据的操纵都将被延迟。本次事务提交后解锁。
而hibernate灰心锁的详细实现如下：
String sql="查询语句";
Query query=session.createQuery(sql);
query.setLockMode("工具"，LockModel.UPGRADE);
说到这里，就提到了hibernate的加锁模式：
LockMode.NONE：无锁机制。
LockMode.WRITE：Hibernate在Insert和Update记录的时候会自动获取。
LockMode.READ：Hibernate在读取记录的时候会自动获取。 这三种加锁模式是供hibernate内部利用的，与数据库加锁无关。
LockMode.UPGRADE：操作数据库的for update字句加锁。 这种模式需要区分前三种模式，该模式是与数据有关的（for update）
在这里我们要留意的是：只有在查询开始之前（也就是hiernate生成sql语句之前）加锁，才会真正通过数据库的锁机制加锁处理惩罚。不然，数据已经通过不包括for updata子句的sql语句加载进来，所谓的数据库加锁也就无从谈起。 可是，从系统的机能上来思量，对付单机或小系统而言，这并不成问题，然而假如是在网络上的系统，同时间会有很多联机，假设有数以百计或上千甚至更多的并发会见呈现，我们该怎么办？假如比及数据库解锁我们再举办下面的操纵，我们挥霍的资源是几多？–这也就导致了乐观锁的发生。
乐观锁
乐观锁定（optimistic locking）则乐观的认为资料的存取很少产生同时存取的问题，因而不作数据库条理上的锁定，为了维护正确的数据，乐观锁定回收应用措施上的逻辑实现版本节制的要领。
譬喻若有两个客户端，A客户先读取了账户余额100元，之后B客户也读取了账户余额100元的数据，A客户提取了50元，对数据库作了改观，此时数据库中的余额为50元，B客户也要提取30元，按照其所取得的资料，100-30将为70余额，若此时再对数据库举办改观，最后的余额就会不正确。
在不实行灰心锁定计策的环境下，数据纷歧致的环境一但产生，有几个办理的要领，一种是先更新为主，一种是后更新的为主，较量巨大的就是查抄产生变换的数据来实现，或是查抄所有属性来实现乐观锁定。
Hibernate 中透过版本号查抄来实现后更新为主，这也是Hibernate所推荐的方法，在数据库中插手一个VERSON栏记录，在读取数据时连同版本号一同读取，并在更新数据时递增版本号，然后比对版本号与数据库中的版本号，假如大于数据库中的版本号则予以更新，不然就回报错误。
以适才的例子，A客户读取账户余额1000元，并连带读取版本号为5的话，B客户此时也读取账号余额1000元，版本号也为5，A客户在领款后账户余额为500，此时将版本号加1，版本号今朝为6，而数据库中版本号为5，所以予以更新，更新数据库后，数据库此时余额为500，版本号为6，B客户领款后要改观数据库，其版本号为5，可是数据库的版本号为6，此时不予更新，B客户数据从头读取数据库中新的数据并从头举办业务流程才改观数据库。
以Hibernate实现版本号节制锁定的话，我们的工具中增加一个version属性，譬喻：
public class Account { private int version; ....
public void setVersion(int version) { this.version = version; }
public int getVersion() { return version; } .... }
而在映像文件中，我们利用optimistic-lock属性设定version节制，<id>属性栏之后增加一个<version>标签，如下：
<hibernate-mapping> <class name="onlyfun.caterpillar.Account" talble="ACCOUNT" optimistic-lock="version"> <id..... /> <version name="version" column="VERSION" /> .... </class> </hibernate-mapping>
设定好版本节制之后，在上例中假如B 客户试图更新数据，将会激发
StableObjectStateException破例，我们可以捕获这个破例，在处理惩罚中从头读取数据库中的数据，同时将 B客户今朝的数据与数据库中的数据秀出来，让B客户有时机比对纷歧致的数据，以抉择要改观的部份，可能您可以设计程式自动读取新的资料，并反复扣款业务流程，直到数据可以更新为止，这一切可以在配景执行，而不消让您的客户知道。
#p#分页标题#e#
可是乐观锁也有不能办理的问题存在：上面已经提到过乐观锁机制的实现往往基于系统中的数据存储逻辑，在我们的系统中实现，来自外部系统的用户余额更新不受我们系统的节制，有大概造成犯科数据被更新至数据库。因此我们在做电子商务的时候，必然要小心的留意这项存在的问题，回收较量公道的逻辑验证，制止数据执行错误。
也可以在利用Session的load()或是lock()时指定锁定模式以举办锁定。 假如数据库不支持所指定的锁定模式，Hibernate会选择一个符合的锁定替换，而不是丢出一个破例。
