oracle丢失更新与悲观锁定

      上一节已经介绍了丢失更新问题，如何解决这个问题有两种机制：悲观锁定和乐观锁定。这一节介绍悲观锁定。

      用户在屏幕上修改值之前，这个锁定方法就要起作用。例如，用户一旦有意对他选择的某个特定行（屏幕上可见）执行更新，如单击屏幕上的一个按钮，就会放上一个行锁。也就是说，当用户点击界面上修改按钮的时候，就应该给要修改的那一条记录加一个行锁。
      只要用户从数据库取出一条记录，准备更新，就给这条记录加一个行锁。因为我很悲观，我不知道用户是否会更改这条记录。

      打个比方：后台管理员1查询用户信息，单击某一个用户信息想对他进行修改。这个时候的SQL语句应该是这样的：

select * from t_user_info where userId=**** for update nowait。 后面的for update nowait语句就给这一行加了一个行锁，任何用户只能够查看这个用户的信息，而不能够进行修改。当这条语句到达数据库执行的时候会遇到这几种情况：

      1. 还没有人对这位用户的记录加行锁，后台管理员1加锁成功！

      2. 已经有人对这位用户的记录加了行锁，后台管理员1加锁失败，我们就会得到一个ORA-00054：resource busy（ORA-00054：资源忙）错误。相应地，必须等待更新这一行的用户执行工作。

      oracle9i&10g编程艺术书中还说了一种情况（我认为不会发生）：

      在选择数据和指定有意更新之间，如果有人已经修改了这一行，我们就会得到0行。这说明，屏幕上的数据是过时的。为了避免前面所述的丢失更新情况，应用需要重新查询（requery），并在允许在最终用户修改之前锁定数据。

      不知作者是否是这个意思，当点击某个用户要更新该用户数据的时候，不从数据库重新读取该用户数据，只是对该用户数据是否已经修改了进行判断。如果已经修改则返回一个已修改标识，说明我们以前读取的该用户数据已经无效，反之，则有效。如果无效，则重新读取该用户数据。那样的话岂不是很麻烦，需要把我们先前读取的该用户所有数据都传进去，与数据库中该用户的数据进行比对。那何不就重新读取该用户的数据呢？不知大家怎么理解？

      注：oracle9i&10g编程与艺术。

 

评论

2 楼 liwenshui322 2010-07-15  

jychenok 写道

你说的那种解决方式，用户A进入编辑界面..其他所有用户就只能进行等待，如果用户A不确认修改则相关单据的所有业务就停在那里无法并行。

所以你下面说的那个问题我觉得才是比较好的解决方式，即选择数据的时候并不进行锁定，仅仅在点击保存按钮的实点时，进行判断（可以通过比较ts实现），如果发现界面上的ts小于实际ts，那么就认为屏幕上的数据时过时的，需要重新查询重新修改...这样也可以避免更新丢失问题。

    这个方法的确不错，不过这个应该是乐观锁定了！悲观锁定应该只是个理论上的东西，没多大的应用价值。

1 楼 jychenok 2010-07-15  

你说的那种解决方式，用户A进入编辑界面..其他所有用户就只能进行等待，如果用户A不确认修改则相关单据的所有业务就停在那里无法并行。

所以你下面说的那个问题我觉得才是比较好的解决方式，即选择数据的时候并不进行锁定，仅仅在点击保存按钮的实点时，进行判断（可以通过比较ts实现），如果发现界面上的ts小于实际ts，那么就认为屏幕上的数据时过时的，需要重新查询重新修改...这样也可以避免更新丢失问题。