我开发过的所有企业JAVA应用程序，都是直接执行SQL语句的。早期的程序是执行特定的SQL语句的，后来是用持久层构架再用少量的SQL语句构成的。一开始我直接用JDBC来执行SQL语句，但是后来，我经常写一些小的构架去完成JDBC中那些比较无聊的部分。我也用过一段Spring的JDBC类，这些类除去了JDBC中的许多样板代码。但是无论是我自己写的构架还是使用Spring的类，在Java类映射到SQL语句的时候都会存在问题，这就是我为什么那么高兴的加入iTATIS 那边的原因了。

　　iBATIS 不仅将应用程序完全的与“数据库连接”、具体的SQL语句隔绝开来，更实现了通过XML描述文档来将JavaBean 映射到SQL语句。它用Java bean 内省机制来将“道具bean（bean properties）”映射为相应的数据库语句占位符，而且它可以将ResultSet后的结果构造为bean.它还可以通过数据库生成主键，自动加载相关的对象、实现缓存和lazy loading.这样，iBATIS 就除去了许多执行SQL语句带来的苦差。通过编辑XML描述文档和调用少量的iBATIS的API，代替了写大量的JDBC底层代码。

　　使用持久层框架

　　当然，iBATIS不能实现高层开发和维护SQL语句，而且缺乏可移植性。为了避免这类问题，你需要用到持久层框架。持久层框架可以将对象域映射到数据库中。它提供了创建，查找，删除对象的API函数。当程序要控制对象时它可以自动的加载相应的对象，还可以在事务处理结束时自动更新数据库。持久层框架通过对象/关系映射机制可以自动的生成SQL语句，对象/关系映射机制用XML文档定义了怎样将类映射为表，怎样将数据映射为列（column）和关系是怎样被映射为外键与连接表的。

　　在持久层构架上EJB也有它的短处：实体bean.EJB2的实体bean有很多的不足，而且开发和测试它会变得非常的枯燥。最后，很少用EJB2的实体bean了。在EJB3中会说明那些问题。

　　两种最有流行的轻量级持久层构架是JDO和Hibernate，前者是Sun的标准框架，后者是开源工程。两种框架都可以为POJO类提供持久层事务处理。你可以用POJO类来开发和测试你的业务逻辑，而不用担心持久层的问题，这个时候它会将类映射到数据库中的schema.另外，他们两个都可以在服务器程序外部或者内部，这样可以进一步降低开发难度。用Hibernate和JDO来进行开发比用老的EJB2的实体bean要舒服的多。

　　除了要决定怎样访问数据库外，还要决定如何处理数据库的并行处理问题。下面来看一下，为什么并行处理问题那么重要，同时看一下可实现的选项

　　决策4：处理数据库事务处理的并行问题

　　差不多所有的企业应用程序都需要多用户和多个后台进程并行的更新数据库。2个数据库 处理事务同时访问同时访问同一个数据是很正常的，但是这种情况很可能引起数据库中的数据不一致或者引起应用程序的不正常。由于大部分的应用程序都需要处理多个处理事务并行访问同一个数据，则它可以影响到业务和持久层的设计。

　　无论你是使用EJB还是轻量级构架，你的程序必须可以并行访问共享数据。EJB2要求使用供应商提供的特殊扩充接口来实现并行，然而与此不同的是，JDO和Hibernate可以直接支持大部分并行机制。更重要的是，使用JDO和Hibernate不仅只配置简单，而且只需要少量的代码就可以实现了。

　　在这样主要介绍几种“并行更新数据库处理事务”的选项的概要，这些事务处理和用户的输入无关。下一章，我主要介绍一下如何在应用程序级长时间的并行更新数据库处理事务，这种处理事务会与用户输入有关，而且是由一系列的数据库事务处理组成的。

　　独立数据库事务

　　有时候对共享数据的并行访问可以简单的依靠数据库本身来实现，数据库可以设置为执行孤立的数据――这只是对数据库而言。如果你对这种概念不熟悉也不要担心，你只要记住：如果应用程序使用完全的孤立事务方式，那么同时执行2个事务的结果和一个接一个的执行是一样的。（也就是说，如果你用孤立事务的方式来访问数据库的话，你同时执行2个事务，就会变成一个接一个的串行执行了。）

　　这种方法也许听起来非常的简单，但问题是这种处理方式有时候会降低性能，因为如何实现对事务的孤立是由数据库来决定的。为了这个原因，许多应用程序都避免使用它，而采用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中详细介绍。

　　开放式脱机锁定

　　模式一种选择是开放式锁定机制的扩展，它会从第一次读取数据开始，在编辑进程执行后检查数据是否已经被修改了。例如，你可以在数据库的共享数据的表中使用版本号来实现。在编辑进程开始的时候，程序将版本号存储到会话状态中，然后每次用户要存储数据时，应用程序都要进行检查，保证数据库中的版本号和会话状态中的版本号一致。

　　因为开放式脱机锁定模式只有在用户进行保存修改过的数据时才可以检测，所以它只有在不成为客户的累赘的时候，才可以很好的运行。但如果情况是：客户必须要撤销几个操作的话，那么就会因为这种锁定模式而非常苦恼，那么更好的一种选择是用保守式脱机锁定。

　　保守式脱机锁定

　　模式在编辑进程开始时，保守式脱机锁定方式通过锁定 共享数据，来解决 多个数据库事务 同时更新共享数据的问题，这样，这个编辑进程就可以防止 其他的用户来修改数据了。这种方式和保守式锁定机制一开始描述的很类似，但它是靠程序来实现的，而不是数据库。因为同一时间内，只有有权利编辑共享数据的用户，才有权利去保存这些修改。

[1] [2] [3]