`
凤凰山
  • 浏览: 147191 次
  • 性别: Icon_minigender_1
  • 来自: 重庆
社区版块
存档分类
最新评论

《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,不需要显式声明或者处理的异常)来报告并发失败要好得多。
--------------
分享到:
评论

相关推荐

    Manning - Pojos In Action.pdf

    《Pojos In Action》这本书由Chris Richardson撰写,聚焦于使用POJOs(Plain Old Java Objects)设计轻量级Java企业应用的关键问题,通过深入的实例解析,为读者提供了实践指导。该书不仅扩展了Martin Fowler的...

    Manning - Pojos In Action

    《Pojos in Action》是一本专注于Java编程领域中Plain Old Java Objects(POJOs)技术的专业书籍。这本书由Manning出版社出版,旨在深入探讨如何在实际开发中有效地使用POJOs,以及它们在现代Java应用程序设计中的...

    POJOS in Action

    通过阅读《POJOS in Action》,读者可以深入了解POJOs的精髓,学习如何在现代Java应用中充分利用它们,从而提升代码质量,提高开发效率。这本书对Java开发者,尤其是那些希望深入理解Spring和其他轻量级框架的开发者...

    POJOS IN ACTION开发轻量级企业应用程序

    POJOS IN ACTION开发轻量级企业应用程序

    POJOs.in.Action

    ### POJOs in Action:利用轻量级框架开发企业应用 #### 一、概述与背景 《POJOs in Action》是一本针对轻量级Java企业应用开发的实践指南。该书通过构建一个完整的应用程序来深入探讨POJO(Plain Old Java Object...

    pojos_in_action_-_src.zip

    《Pojos in Action - 源码探索与工具运用》 "pojos_in_action_-_src.zip" 这个压缩包文件,暗示我们它包含了与《Pojos in Action》一书相关的源代码。这本书主要讲解了Plain Old Java Objects(POJOs)的使用和实践...

    pojos in action

    《Pojos in Action》是一本深入探讨Java轻量级解决方案的经典教程,它主要针对企业级应用开发领域,尤其关注EJB(Enterprise JavaBeans)编程模型的局限性以及为何转向POJOs(Plain Old Java Objects)和轻量级框架...

    《POJOs in Action》(pdf)英文版下载

    本书摘自Chris Richardson撰写的POJOs in Action (ISBN 1932394583),由Manning Publications公司出版,版权所有:2006年。 博文链接:https://projector.iteye.com/blog/209555

    狂神笔记.md文件.zip

    它将接口和Java的POJOs(Plain Old Java Objects,普通的Java对象)映射成数据库中的记录,极大地简化了数据访问层的开发。 2. **Spring**:Spring是一个开源的应用框架,它是为了解决企业应用开发的复杂性而创建的。...

    Manning.Spring.in.Action.4th.Edition.2014.11.epub

    Praise for the Third Edition of Spring in Action Preface Acknowledgments About this Book 1. Core Spring Chapter 1. Springing into action 1.1. Simplifying Java development 1.1.1. Unleashing the power ...

    ssm读书笔记.docx

    POJOs通常用于表示数据模型,它们可以作为DTO(Data Transfer Objects)来传输数据,或者作为简单的值对象来存储和传递信息。 一个典型的POJO类通常包含以下元素: 1. 私有属性(private fields):这些属性代表了...

    MyVo Generate POJOs.groovy.zip

    在给定的压缩包文件"MyVo Generate POJOs.groovy.zip"中,包含了一系列以"Generate POJOs.groovy"命名的脚本,如"My Generate POJOs.groovy"、"MyDto Generate POJOs.groovy"、"MyInsertDto Generate POJOs.groovy...

    Generate POJOs.groovy

    IDEA通过Generate.POJOs.groovy映射数据库自动生成对应的Java实体类, 具体逻辑不详细展示,可参考:https://blog.csdn.net/weixin_40375601/article/details/106807644

    Pojos In Action

    ### Pojos In Action #### 知识点一:POJO概念与重要性 - **POJO定义**:Plain Old Java Object(POJO)是简单的Java对象,它不是任何框架的一部分,也不实现任何特殊接口,通常用于封装数据或业务逻辑。 - **POJO...

    commercial-pojos-1.0.0-RC17.jar

    commercial-pojos-1.0.0-RC17.jar

Global site tag (gtag.js) - Google Analytics