OpenSessionInView详解

TX1 和 TX2 是两个并发事务:

TX1 是给一个物品降价10块钱, 看是不是已经有合适的买家.

TX2 是出价160块, 看是不是竞拍到了这个物品.

在两个事务开始的时候都要先查询一下该物品是否已经被拍下.

这个查询对于未经任何优化的关系数据库来说, 要保证数据一致性, 就必须在这个查询提交之后, 进行查询的事务结束之前, 锁定 Item 和 Bid 表, 一方面防止符合查询条件的Item表记录被修改,新增或者删除, 另一方面防止TX1和TX2这两个事务冲突, 造成数据一致性受损, 比如出来两个Bid记录的win都是TRUE的可能.

因为这个例子比较简单, 所以进行优化相对容易, 就是不锁定整个Item 和Bid表, 而是锁定Item表里id为321和Bid表里itemid为321的所有记录, 包括不允许插入也不允许删除这样的记录.

在这个简单的例子里, 经过这样优化以后, 所达到的效果和TOB相当, 也就是只锁定item 321相关的数据, 允许对其他无关记录的并发操作. 因为TOB是在调用以@Reading标准的方法时对该对象加读取锁(TOB可以配置为使用乐观锁也可以使用悲观锁). 也就是调用 item.o.getBids() 的时候对item加了读取锁, 另一个并发事务如果想向item.o.bids这个集合中加对象进行修改的话, 就要等先获得了这个锁的事务提交或者回滚以后才能继续执行(用悲观锁时), 或者在最后提交的时候抛出一致性异常,自动回滚(用乐观锁时).

但是现实应用中, 常常有很多复杂的组合或者广泛引用的查询条件, 对这些查询条件的类似并发控制优化就体现了不同数据库产品的真正差别. 另外优化也会增加更多的陷阱, 需要这样或者那样的workaround, 同时错误使用甚至正常使用时碰到了优化的bug, 数据也可能被破坏, 这时候数据恢复特性又被提上日程. 其实像Oracle这种CRUD裸性能不知道比MySQL慢多少, 但是就是更值钱, 其中部分就应该包含这里的原因.

但是这些问题的终极源头还是关系模型, 数据以记录条形式进行物理存储, 数据之间的关系只是存在于逻辑层次上, 也就决定了必须通过动态的JOIN查询来临时关联构造出数据拓扑结构来, 因为JOIN的复杂性导致难以维护格记录条的权威版本.

而以加上了面向对象特性的ORK模型为基础, TOB的持久模型是容器维护的一个物理的对象拓扑结构图, 不仅各个节点有了权威版本的控制中心, 从而并发控制的成本戏剧性降低, 直接进行拓扑结构遍历的业务逻辑更是得到极端的性能提升 (比ORM数据都在缓存中的情况都要快得多).

你和我说的根本不是一个东西。。。。。

好好的一个帖子又偏题了。

我已经提交到 spring jira , 具体情况可以看 http://opensource.atlassian.com/projects/spring/browse/SPR-2785

Juergen Hoeller 给了答复, 我的问题还是没办法解决, 只能绕过去了

呵呵, 过来凑了个热闹, 数落一下 RDB/ORM 的缺陷, 请不要介意.