《POJOS in Action》读书笔记

前言：好久没有系统性的看过书了，早就听说《POJOs in Action》是本好书，可惜自己一直不能静下心来学习，此次在博客上记录我的学习笔记原因有两点，第一是想通过博客来监督我把这本书读完，其二是觉得自己总是在互联网上“剽窃”人家的学习成果，而自己从来都没有为大家贡献自己的成果，实在是有点内疚，希望我的学习笔记对大家有所帮助。

系统设计时需要考虑的五大因素：

1、如何组织业务逻辑

2、如何封装业务逻辑，以及暴露给表示层及其他客户程序调用的接口

3、如何访问数据库

4、如何处理短事务中的并发

5、如何处理长期运行事务中的并发

决策	选项
业务逻辑封装	EJB Session Façade模式 POJO Façade模式 Exposed Domain Model模式
数据库访问	直接使用JDBC iBATIS Hibernate JDO
数据库事务中的并发	不理睬该问题 悲观锁 乐观锁 可串行化隔离级别
长期运行事务中的并发	不理睬该问题 Pessimistic Offline Lock模式 Optimistic Offline Lock模式

以上5个决策每个都有多种选项。基于EJB的设计，它由会话bean实现的过程式代码组成，并使用JDBC访问数据库。相比之下，基于POJO的设计由对象模型组成，通过JDO、Hibernate等O/R框架映射到数据库，并用使用Spring进行事务管理的POJO façade进行封装。每种选项都有优缺点，这也决定了它只能适用于某种具体情况。每种选项都会在一个或多个方面做出一定的妥协，包括功能性、开发难易度、可维护性和可用性等，需要自己的应用程序作出最佳选择。

 

封装业务逻辑

业务逻辑的接口由那些可被表示层调用的类型（type）和方法（method）组成。接口设计的要点是应当封装多少业务逻辑的实现，并对表示层不可见。封装隐藏了业务逻辑的实现细节，可以防止表示层受业

务逻辑变化的影响，从而提升可维护性。同时还需考虑怎样处理事务、安全性和远程调用等问题，因为通常这些都是业务逻辑接口代码的职责。一般来说，业务层接口应保证对业务层的每个调用都在事务中执行，以便保证数据库的数据一致性。同样的，业务层接口还要验证调用者是否有足够的权限来调用某种业务方法。此外，它还要负责处理某些远程客户端。

   若存在表示层远程访问业务层API的情况，尽量将业务层的API设计成粗粒度的，这样对业务层的调用越少，数据库事务数量就越少，内存缓存对象的机会就越多。还能减少网络来回传输次数。

单个数据库事务中的并发

完全事务脚本、乐观（optimistic）锁、悲观（pessimistic）锁

完全事务脚本是一种解决方案是使用完全和其他事务隔离的事务，用数据库的话来说，就是隔离级别为serializable（串行化）的事务（悲观锁的另一种方案）。数据库保证：执行多个 serializable事务的结果和一个个串行执行它们的结果一样。serializable事务避免了更新丢失、读取不一致等问题。一些数据库还提供了repeatable read（能够保持一致的重复读取）和Read committed的隔离级别，完全隔离事务有两个主要优点：一是使用简单；二是避免了很多并发问题，包括修改丢失和读取不一致的问题。完全隔离事务的主要缺点是开销太大，降低了性能和规模扩展性，不管有没有并发更新，都需要额外开销。而且，由于死锁和其他并发相关问题，完全隔离事务比低隔离级别的事务的失败频率更高。用serializable或者repeatable read隔离级别的事务，这种方案不需要数据库模式变化。因为数据库的serializable事务机制能够处理并发更新，所以不需要用语句来锁住记录，也不需要维护版本号。在spring中可以通过配置数据源的属性“defaultTransactionIsolation”为“SERIALIZABLE”来实现。

  乐观锁的工作原理是让应用程序检查它即将更新的数据是否已被另一个事务修改（自该数据上次读取以来）。实现乐观锁的一种常见做法是在每个表里添加一个版本字段，每次应用程序更新数据表记录时就增加这个版本字段。每个UPDATE语句中的WHERE子句会根据上次读取的值来判断这个版本号是否改变。使用诸如JDO和Hibernate的持久层构架时，实现乐观锁更为容易，因为它们已将乐观锁作为配置选项提供。

    应用程序或持久层框架有三种方法可以判断一条记录自从上次读取出来后是否被修改过。
    第一种方法是 用一个version（版本）字段来跟踪记录修改状况，每次修改，version都会递增。事务只需要把原来读出的 version和当前version进行比较，就可以判断一条记录是否被修改过。应用程序检查和修改version字段是比较简单的做法，通常也是最好的做法。

第二种方法是用时间戳字段，每次应用程序修改数据，时间戳也会更新。事务只需要把原来读出的时间戳和当前时间戳进行比较，就可以判断一条记录是否被修改过。这个表结构也很容易实现，尤其是这种情况下，数据表经常已经有一个时间戳字段来记录用户修改记录的时间。然而，时间戳的问题是，如果两个修改操作之间的时间差小于时钟最小单位，那么一个事务可能覆盖另一个事务的 修改。所以，只有在无法增加version字段的遗留系统中，才应该使用时间戳，否则，尽量使用version（版本）。

第三种方法是把上次读出的字段值和现有字段值进行比较。这种方法最大的好处是，不需要引入version或者时间戳字段，所以可以用在遗留系统中。这个方法的一个缺点是使得SQL UPDATE更加复杂，因为WHERE子句里面包含所有的字段的条件（具体原因我们后面会详述）。还必须正确处理null字段，可能比较复杂。比如，有一 次我发现，一个持久层框架不能正确比较空字符串，因为Oracle把空字符串认为是null，这和Java不一样。我们在数据表里面增加了一个版本字段， 解决了这个问题。

第三种方法的另一个缺点是，浮点数字段不能精确比较，浮点数字段的修改可能发现不了。由于这些问题，应用程序只有在别无选择，无法应用版本和时间戳的情况下，才应该使用这种方法。

悲观锁的工作原理是当读取某些记录时，事务先锁住这些记录，这样可以防止其他事务访问这些数据记录。具体细节要视数据库而定，不过糟糕的是，并非所有数据库都支持悲观锁。如果数据库支持悲观锁，在直接执行SQL语句的应用程序中，实现悲观锁非常容易。在JDO或Hibernate应用程序中使用悲观锁更为容易。JDO以配置选项的方式提供悲观锁，而Hibernate则提供一个简单实用的API，来锁定对象。
    获取锁的机制是数据库相关的，并非所有数据库都支持。在Oracle数据库中，应用程序通过SELECT FOR UPDATE语句锁住选出的记录，从而实现悲观锁。如果已经有事务锁住记录，执行SELECT FOR UPDATE语句的事务就会被阻塞。如果其他事务更新、删除或者试图用SELECT FOR UPDATE选取这些记录，阻塞情况就会发生。事务一直阻塞，直到事务提交或者回滚。如果事务不想等待，可以采用SELECT FOR UPDATE NO WAIT，如果不能立即锁住记录，就返回ORA-00054错误。你还可以用SELECT FOR UPDATE WAIT 来指定等待时间。要注意的是：一些数据库对SELECT FOR UPDATE的用法有限制。例如，Oracle里面，SELECT FOR UPDATE只能用在顶层SQL，而不能嵌在子查询里面。还有一些SQL特性不能和SELECT FOR UPDATE一起使用。这些特性包括DISTINCT，集合统计函数（max、min、sum、count），GROUP BY。SELECT FOR UPDATE也不能用在某些类型的view和嵌套的SELECT里面。

处理长事务中的并发

乐观离线锁( Optimistic Offline Lock) 模式、悲观离线锁( Pessimistic Offline Lock )模式

乐观离线锁模式是扩展此前描述的乐观锁机制，在编辑过程的最后一个数据库事务里，检查数据自最初读取后并未改变。例如，你可以使用共享数据表里的版本号字段实现 这一机制。在编辑过程开始时，应用程序先将版本号存储在会话状态里。然后，当用户保存其更改时，应用程序进行检查，保证会话状态里保存的版本号和数据库中的版本号一致.由于乐观离线锁模式只在用户要保存修改后的数据时才进行检测，在实现诸如“修改订单”用例时，要用户放弃好几分钟才完成的操作，用户肯定会非常恼火，此时更好的选择是使用悲观离线锁.
悲观离线锁模式是在编辑过程开始之初，就锁定共享数据，以防止其他用户编辑该共享数据。这种方式与此前描述的悲观锁机制类似，只不过这里锁由应用程序而不是数据库实现。由于每次只有一个用户能编辑共享数据，因此可保证用户能保存自己的修改。

通知并发更新失败

当DAO或者数据库认为当前的两个事务不能并发运行时，就会发生并发失败。DAO可以允许JDBC SQLException传播到DAO的调用者。不过，有两个原因说明这种做法不是一个好主意。抛出SQLException的第一个问题是JDBC相 关。应用程序也可以使用JDO这样的持久层，但是抛出其他的非JDBC异常。理想情况下，更高层的应用程序组件不应该知道底层访问了数据库。 SQLException的另一个问题是，SQLException是一个checked exception（非Runtime Exception，需要显式声明或者捕获的异常），需要DAO调用者或者捕捉SQLException，或者在方法签名上声明继续抛出 SQLException，这种情况下，调用者代码会变得杂乱。使用unchecked exceptions（Runtime Exception，不需要显式声明或者处理的异常）来报告并发失败要好得多。