摘要: Client Session State 客户会话状态.在Client端保存会话状态.运行机制Client在每次请求时会把所有的会话数据传给Server,Server在响应时把所有的会话状态传给Client.可以是完全无状态的Server.通常使用可序列化的DTO对象来传递数据.在HTML中,可选的是:URL参数,表单的隐藏域,Cookie.使用时机支持无状态的Server对象.从而提供了最大的集群性能和容错恢复.适合于小数据量.当数据量大时,保存和传输会有较大的延迟.安全问题.所有送到客户的数据都很容易泄露或被篡改.而加密又会影响性能.会话标识号一般使用Client会话状态.Server S 阅读全文
posted @ 2014-01-21 15:20 robynhan 阅读(461) 评论(0) 推荐(0) 编辑
摘要: 用一个锁Lock一组相关的对象有时,需要按组来修改多个对象.这样,在需要锁住其中一个的时候,必须连带地将其他的对象都上锁.为每一个对象都加上一个锁是很繁琐的.粗粒度锁是覆盖多个对象的单个锁.简化了加锁行为.且不必为了给它们加锁而加载所有对象.运行机制为一组对象建立一个控制点.使用乐观离线锁让组中每个对象共享一个版本号来建立一个控制点.增加这个版本号时,就成为一个锁住组中所有对象的共享锁.需要在模型中指定该组的每个对象.共享的悲观离线锁要求组中每个对象共享某种锁标记.通过这个锁标记来锁住它们.一个共享的版本对象就是最好的锁标记.作为数据修改的基本单位的一组相关对象可看成一个aggregate聚集 阅读全文
posted @ 2014-01-21 14:23 robynhan 阅读(1405) 评论(0) 推荐(0) 编辑
摘要: 每次只允许一个业务事务来访问数据,以防止并发业务事务中的冲突.离线并发处理通常会出现多个业务事务操作同一数据.最简单的办法是为整个业务事务保持一个系统事务.但是事务系统不适合于处理长事务.首选乐观离线锁.而悲观离线锁,作为它的补充.从一开始就避免冲突.它要求业务事务在对数据进行操作前就必须获取该数据的锁.一旦开始了一个业务事务,就确信不会再提交时由于并发冲突而被迫回滚数据.运行机制决定使用哪种锁exclusive write lock独占写锁.写目的的会话数据时使用,当对数据的读取要求不高时.exclusive read lock独占读锁.仅是为了读目的时的数据.限制了并发性.read/wri 阅读全文
posted @ 2014-01-21 12:28 robynhan 阅读(531) 评论(0) 推荐(0) 编辑
摘要: 通过冲突检测和(发生冲突时的)事务回滚,来防止并发业务事务中的冲突.通常一个业务事务的执行,会跨越一系列的系统事务.一旦超出了单个系统事务的范围,就不能仅依靠DB管理程序来保证数据一致性.乐观离线锁假设冲突的发生可能性很小.使多用户并发地对同一份数据进行处理成为可能.在同一业务事务中,进行预验证和对数据的修改.一个成功的预验证可以视为得到一个锁,来表示能够成功地完成对数据的修改.运行机制原理:通过检查在(业务事务)会话读取一条记录后,没有其它的会话修改该记录来保证数据的一致性.可以在任何时间获取该锁,但是它只在获得该所的系统事务过程中有效.系统事务中只有有对DB的修改,就需对每个变更成员申请该 阅读全文
posted @ 2014-01-21 11:52 robynhan 阅读(854) 评论(0) 推荐(0) 编辑
摘要: Remote Facade远程外观在OO模型中,存在很多规模小,且有小方法的对象.这些小对象会导致很多的对象间交互.在单一地址空间里,小对象没问题.但是,当在两个进程间做调用时,频繁的跨进程交互会造成性能开销.远程外观,减少远程调用的次数.建立在大量的细粒度对象之上,提供一个粗粒度的外观.不包括任何的领域逻辑.只是将方法转换到细粒度对象上.运行机制细粒度对象适合于解释复杂的逻辑.远程外观使用bluck accessor来使用一个getter/setter来完成在细粒度对象中的所有gettter/setter.单个远程外观,也可以作为多个细粒度对象的一个远程入口.远程外观的设计基于特定的客户需求 阅读全文
posted @ 2014-01-21 09:55 robynhan 阅读(573) 评论(0) 推荐(0) 编辑