这种方法也许听起来非常的简单，但问题是这种处理方式有时候会降低性能，因为如何实现对事务的孤立是由数据库来决定的。为了这个原因，许多应用程序都避免使用它，而采用optimistic或者pessimistic 所锁，这会在下面讲到。
开放式锁定
并行更新数据的一种途径是用开放式锁定。开放式锁定工作原理是通过应用程序来检查数据是否被更新（被其他事务修改造成的）而实现的。一种更普通的实现开放式锁定的方法是在每个表中添加一个“版本列”（version column），对每个表而言，程序每次改变其中一行的时候都会更新这个“版本列”。每个UPDATE语句中的WHERE语句会根据上次查询的结果判断这个版本号是不是被更改了。在事务访问数据库中的数据时，程序中可以用PreparedStatement.executeUpadte（）这个函数的返回值来检查行的个数，从而判断是否要继续执行UPDATE语句。如果数据中的行已经被其他的事务更新或者删除了，那么程序会让该事务从新访问数据库。
用开放式锁定机制来锁定那些直接执行SQL语句的应用程序是非常简单的。但是，用持久层构架（比如JDO和Hibernate）实现更容易，因为他们已经提供了开放式锁定机制――在配置选项中。一旦在配置选项中，选中了这种方式，持久层构架会自动的生成SQL的UPDATE语句来完成版本检查的任务。开放式锁定的名字来源于一种假设的情况，在这种情况下：并发更新的机会非常少，而且程序只能检测、覆盖这些数据而不能防止这种事情的发生。另外一种可选的途径是用保守式锁定，使用他的假设条件是：并发更新肯定会发生，而且必须被禁止。
保守式锁定
对于开放式锁定来说，另外一种途径是使用保守式锁定。当一个事务读取某些行的数据时，他会对这些数据加锁，这样就防止其他的事务访问这些数据了。具体的实现是需要数据库支持的，然而不幸的是，不是所有的数据库都支持保守式锁定。如果你的数据库支持话，那么你的应用程序直接执行SQL语句来实现保守式锁定将非常容易。但是，可能你已经猜到了，在程序中用JDO或者Hibernate来实现保守式锁定更容易，JDO以配置选项的方式提供了保守式锁定，而Hibernage提供了简单的API实现锁定对象。
除了可以处理单个数据库事务并行问题，常常你还需要处理多数据库事务的并行问题。
决策5：在长事务下处理并发访问
独立事务、开放式锁定、和保守式锁定只能用在单个数据库事务上的，然而，许多的程序需要 长时间的 在多个数据库事务之间 读取或者更新 共享数据。比如，有一种情况描述的是 怎样实现 用户编辑命令，这和很多的进程有关，这些进程可能会运行 很长的时间，而且它由 多个数据库事务组成。因为数据可能会被 一个数据库事务 读取，而又被 另外一个数据库事务 修改了，那么程序必须对 共享数据的并发访问 进行不同的处理。这样就必须使用 开放式锁定设计模式或 者保守是锁定设计模式，关于这两种模式会在Fowler的 Patterns of Enterprise Application Architecutre中详细介绍。
开放式脱机锁定
模式一种选择是开放式锁定机制的扩展，它会从第一次读取数据开始，在编辑进程执行后检查数据是否已经被修改了。例如，你可以在数据库的共享数据的表中使用版本号来实现。在编辑进程开始的时候，程序将版本号存储到会话状态中，然后每次用户要存储数据时，应用程序都要进行检查，保证数据库中的版本号和会话状态中的版本号一致。
因为开放式脱机锁定模式只有在用户进行保存修改过的数据时才可以检测，所以它只有在不成为客户的累赘的时候，才可以很好的运行。但如果情况是：客户必须要撤销几个操作的话，那么就会因为这种锁定模式而非常苦恼，那么更好的一种选择是用保守式脱机锁定。
保守式脱机锁定
模式在编辑进程开始时，保守式脱机锁定方式通过锁定 共享数据，来解决 多个数据库事务 同时更新共享数据的问题，这样，这个编辑进程就可以防止 其他的用户来修改数据了。这种方式和保守式锁定机制一开始描述的很类似，但它是靠程序来实现的，而不是数据库。因为同一时间内，只有有权利编辑共享数据的用户，才有权利去保存这些修改。
