DRP数据库悲观锁

     事务具有四个特性：原子性、隔离性、一致性、持久性。对于数据库的操作也应该具有事务的性质，如果执行正确则返回结果，如果中间出了差错，应该回滚，这样才能保证数据库的数据的真实性。但是在现实操作过程中，往往数据量不是一条两条，而是很多条数据同时操作，这是就要防止并发问题。通常来说，数据库的隔离级别越大，并发性就越差。防止数据库的并发，就有了锁机制的出现。

      在drp项目里，分销商的主键采用了单独的表来生成，这样就会出现多个用户同时生成主键的问题，也就是存在访问共同资源的情况，我们都知道出现了这种情况就必须使用线程同步，保证数据在任何时刻，最多有一个线程访问，以保证数据的完整性。

      目前我知道的解决办法有以下两种：

      1、在Java中使用synchronized关键字对方法同步（synchronized加入到方法上和synchronized(this)两种写法含义是一样的，都是对对象加锁）。

      2、可以使用数据库的悲观锁，下面重点说一下数据库的悲观锁，使用举例：

      悲观锁是采用数据库机制实现的（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据），数据被锁住之后其它用户将无法查看，直到锁释放，而只有提交或回滚事务后锁才会释放，这样就保证了数据的正确性。注意：for update语句只能放在select语句中，因为查询时把数据锁住才有意义。

      延伸：使用hibernate对数据进行操作时，只有在查询开始之前（也就是 Hiberate 生成 SQL 之前）设定加锁，才会真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含 for update子句的 Select SQL 加载进来，所谓数据库加锁也就无从谈起。）

      总结：

          

      在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。

      悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数。

      

       通过学习悲观锁知道了还有乐观锁，之后学习了再来总结乐观锁的知识吧。