- 维护受业务事务影响的对象列表,并协调变化的写入和并发问题的解决.
- 从DB中存取Data时,必须记录增删改动作,以将对DB有影响的数据写会到DB中去.
- 如果在每次修改对象模型时就对DB进行相应的修改,会造成大量小规模的DB调用,降低了速度.
- 工作单元记录业务事务中对DB有影响的所有变化.然后在操作结束后,了解所有需要对DB做的改变.
- 运行机制
- 如何知道应该记录那些对象.可以由调用者实现,或者让发生变化的对象通知工作单元.
- caller registration
- 用户改变了某个对象后,必须将它注册到工作单元.没有注册的对象在提交时都不会写入DB.
- 允许在内存中改变对象而又不将它写入DB.但是,要达到这样的目的,最好做一个显示的拷贝.
- object registration
- 把注册方法置于对象方法(select,set)中.
- 工作单元要么被传递给对象,要么在一个公共的位置上(通常在某些会话对象上).
- unit of work controller
- 工作单元控制所有数据库的读操作.
- 读操作时,产生一个拷贝.在提交时比较当前对象和拷贝对象.
- 加重了提交的负担,但使得只更新真正改变了的域,同时避免了在对象域内执行注册调用.
- 一个折中
- 只拷贝改变了的对象.
- 这需要注册.
- 但是支持有选择的更新.
- 当读多于写操作时,降低拷贝操作的负担.
- 工作单元还能在DB使用引用完整性是用来保证更新顺序.
- 类似地,使用工作单元可以减少死锁的可能性.如果每个事物都按相同的顺序处理需要进行编辑的表,会降低死锁的风险.
- 对象如何找到当前的工作单元.
- 用一张线程范围内的注册表.
- 在方法调用或者创建对象时,将工作单元传递给需要它的对象.
- 都必须保证访问工作单元的线程不超过一个.
- 也可以处理批量更新(batch update).
- 批量更新:把若干SQL命令作为一个单独的单元发送.这样可以在一次单独的远程调用中得到处理.
- 不仅可以用于数据库.还可以作用于任何事物资源,可以调整消息队列和事务监控.
- 使用时机
- 其解决的基本问题
- 记录操作过的各种对象,以便知道在同步内存和DB的数据时需要考虑哪些对象.
- 最简单的方法,每次修改对象时就显式地保存该对象.
- 可以把对DB的更新操作放到最后.这样的话,需要记录已经改变的所有对象.
- 使用变量来实现记录跟踪.但是变量很多时,会很难以管理.变量与事务脚本配合.
- 对每个发生了改变的对象打"脏"标志.
- 工作单元能够把所有的信息保存在一个地方.从而不必再为记录所做的修改做很多操作.
posted @
2014-01-15 11:16
robynhan
阅读(
691)
评论()
编辑
收藏
举报
