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

系统设计时需要考虑的五大因素：
1、如何组织业务逻辑2、如何封装业务逻辑，以及暴露给表示层及其他客户程序调用的接口3、如何访问数据库4、如何处理短事务中的并发5、如何处理长期运行事务中的并发

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

悲观锁的工作原理是当读取某些记录时，事务先锁住这些记录，这样可以防止其他事务访问这些数据记录。具体细节要视数据库而定，不过糟糕的是，并非所有数据库都支持悲观锁。如果数据库支持悲观锁，在直接执行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一起使用。这些特性包—ISTINCT，集合统计函数（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，不需要显式声明或者处理的异常）来报告并发失败要好得多。--------------转载自： http://blog.csdn.net/ilibaba/article/details/3745357