业务逻辑的实现过程中，往往需要保证数据访问的排他性。因此，我们就需要通过一些机制来保证这些数据在某个操作过程中不会被外界修改，这样的机制，在这里，也就是所谓的“锁”，即给我们选定的目标数据上锁，使其无法被其它程序修改。
Hibernate 支持两种锁机制：
1. 悲观锁（Pessimistic Locking）；
2. 乐观锁（Optimistic Locking）；
1.悲观锁
它指的是对数据被外界修改持保守态度。假定任何时刻存取数据时，都可能有另一个客户也正在存取同一笔数据，为了保持数据被操作的一致性，于是对数据采取了数据库层次的锁定状态，依靠数据库提供的锁机制来实现。
select * from account where name = "12345" for update
JDBC对name=”12345”所有记录实现了行级锁。
Hibernate是这样实现的
String hqlStr = "from TUser as user where user.name=‘12345‘";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPDATE);//加锁
List userList = query.list();
说到这里，就提到了hibernate的加锁模式：
LockMode.NONE：无锁机制。
LockMode.WRITE：Hibernate在Insert和Update记录的时候会自动获取。
LockMode.READ：Hibernate在读取记录的时候会自动获取。
这三种加锁模式是供hibernate内部使用的，与数据库加锁无关：
◆ LockMode.UPGRADE：利用数据库的for update子句
◆ LockMode.UPGRADE_NOWAIT：Oracle的特定实现，利用Oracle的for update nowait子句实现加锁
以上二种锁机制是我们在应用层较为常用的，依赖数据库的悲观锁机制。
在这里我们要注意的是：只有在查询开始之前（也就是hiernate生成sql语句之前）加锁，才会真正通过数据库的锁机制加锁处理。否则，数据已经通过不包含for updata子句的sql语句加载进来，所谓的数据库加锁也就无从谈起。
但 是，从系统的性能上来考虑，对于单机或小系统而言，这并不成问题，然而如果是在网络上的系统，同时间会有许多联机，假设有数以百计或上千甚至更多的并发访 问出现，我们该怎么办？如果等到数据库解锁我们再进行下面的操作，我们浪费的资源是多少？--这也就导致了乐观锁的产生。
2.乐观锁
乐观锁定（optimistic locking）则乐观的认为资料的存取很少发生同时存取的问题，因而不作数据库层次上的锁定，为了维护正确的数据，乐观锁定采用应用程序上的逻辑实现版本控制的方法。
一个经典的示例：
若有两个客户端，A客户先读取了账户余额100元，之后B客户也读取了账户余额100元的数据，A客户提取了50元，对数据库作了变更，此时数 据库中的余额为50元，B客户也要提取30元，根据其所取得的资料，100-30将为70余额，若此时再对数据库进行变更，最后的余额就会不正确。
在不实行悲观锁定策略的情况下，数据不一致的情况一但发生，有几个解决的方法，一种是先更新为主，一种是后更新的为主，比较复杂的就是检查发生变动的数据来实现，或是检查所有属性来实现乐观锁定。
Hibernate 中透过版本号检查来实现后更新为主，这也是Hibernate所推荐的方式，在数据库中加入一个VERSON栏记录，在读取数 据时连同版本号一同读取，并在更新数据时递增版本号，然后比对版本号与数据库中的版本号，如果大于数据库中的版本号则予以更新，否则就回报错误。
在映像文件中，我们使用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客户有机会比对不一致的数据，以决定要变更的部份，或者您可 以设计程式自动读取新的资料，并重复扣款业务流程，直到数据可以更新为止，这一切可以在背景执行，而不用让您的客户知道。
但是乐观锁也有不能解决的问题存在：上面已经提到过乐观锁机制的实现往往基于系统中的数据存储逻辑，在我们的系统中实现，来自外部系统的用户余额更 新不受我们系统的控制，有可能造成非法数据被更新至数据库。因此我们在做电子商务的时候，一定要小心的注意这项存在的问题，采用比较合理的逻辑验证，避免 数据执行错误。
也可以在使用Session的load()或是lock()时指定锁定模式以进行锁定。
如果数据库不支持所指定的锁定模式，Hibernate会选择一个合适的锁定替换，而不是丢出一个例外。
3.数据库锁分类
insert是产生表级锁
update是产生行级锁。