TOB - An ORM Replacement Unleashes Real Power Of Java OO Per

这个你有没有可能把Hibernate调优一下(如果同时升到最新版本就更好了)做一个测试结果看看呢? 我一直用的是PolePos的默认配置. Benchmarks的代码在 http://tob.ableverse.org/benchmarks.html 可以下载.
因为TOB是为64位大内存系统设计的, 所以1G以下内存跑这个测试会因为系统颠簸影响TOB发挥, 最好是用1G RAM或者更大内存的机器来跑, 如果你那边环境不方便也可以改一份代码我来跑.


如果每次都触发的话, 恐怕性能牺牲就更多了, 本来就很慢了.


设计TOB应用持久模型的时候有两种选择, 定义@Kin物理引用(集合)或者不定义.
如果定义了的话TOB会自动维护这些引用(集合), 构成运行时的持久对象物理拓扑图. 这种情况下TOB一旦加载一个持久对象, 在把这个对象返回给应用代码之前, 保证把它的整个拓扑图先加载好, 这在TOB的概念里称为将持久对象Set Online. 当然如果内存不够加载所有相关对象就会抛OutOfMemoryError.
如果不定义@Kin引用(集合), 则必需通过对象的持久ID或者SwapEngine提供的查询方法查询获得特定的对象. TOB查询返回的是持久对象集合, 或者一个一个的持久对象传递给应用的PersistentObjectProcessor, 每个持久对象在交给应用之前都会保证Set Online.
当然这两种设计可以按实际情况混合使用.

另外TOB在启动时还有一个目标内存使用百分比可以配置, TOB会在这个指定的百分比允许范围内尽量加载更多对象. 而每一个TOB管理的对象都有一个Online Priority值, 这个值通过其持久类设置默认值, 并且当对象创建以后可以修改. 这个值主要用来确定TOB启动时初始加载对象的优先级. 这样高优先级的对象可以保证在一定的软硬件配置下即使第一次访问也可以在可预测的延迟范围内完成. 应用程序创建TOB实例时TOB会先加载尽可能多的对象, 每成功Set Online一个持久对象(连同它的拓扑结构), 都会检查一次系统空闲内存比例, 如果这个比例降至配置的百分比之下, 就停止继续加载, 或者所有持久对象都成功Set Online, 然后控制才返回给应用程序.

运行时应用不再使用的持久对象可以被Java垃圾回收器回收, 因为TOB对它们的引用都是弱引用. 这样可以为新需要加载的持久对象让出内存空间.

通过@Kin物理连接起来的持久拓扑图必需整个加载, 所以设计模型的时候应该考虑目标环境的内存大小, 决定是不是在持久类上定义@Kin引用(集合).

事务并发控制都是数据库系统来管理的, TOB采用的是MVCC(Multi-Version Concurrency Control)控制算法的一个变种. 因为目前假定TOB应用的写事务不太倾向于会自动撤销, 所以一个持久对象只维护一个可写版本, 而只读版本可能有多个.
持久对象的权威版本只有一个, 是TOB维护的, 且对应用是透明的. 应用(实际上这部分主要应该是框架)只管发起嵌套事务及提交/撤销当前事务或者全部事务. 持久类代码中被加了 @Reading 标注的方法运行期被调用时会自动加读取锁, @Writing 标注的方法会自动加写入锁.

TOB都是在成功写入底层物理存储(底层数据库更新事务成功提交)以后才更新持久对象的权威版本, 所以只要底层数据库有Durability(成功提交的数据保证持久, 这是数据库系统的基本要求之一), 那么TOB维护的持久对象权威版本就总是最权威的数据. 不过这里有一个前提是只有TOB可以写底层的DB Schema, 这就好比同一个交换分区不能让同时运行的两个操作系统使用一样.


冲突的判定和解决还取决于配置的加锁方案. TOB同时支持悲观锁和乐观锁, 但一个TOB实例只能配置一种默认方案, 然后运行时的特定事务实例可以单独改变加锁方案.

悲观锁情况下可以保证成功执行的事务都可以成功提交, 但是争执激烈的并发应用性能会受比较大影响, 应用可能被挂起等锁, 且设计不好的应用有可能造成死锁(死锁的检测和清理就是数据库到操作系统的高级主题了).

乐观锁情况下并发性能基本不受影响, 应用执行时基本不会被挂起, 但是如果发生访问争执, 有些成功执行的事务在提交时就可能被强迫撤销.

楼主，tob与orm的区别之一是：
orm的数据主要是放在rdb中的，orm最多只是利用缓存拿一部分数据放在内存中，而且这部分内容还要时刻注意与rdb保持一致。
tob的数据主要是放在内存中的，rdb只是作为一种对象的持久化手段而已，结果是rdb要注意与tob的数据保持一致，也就是以内存的对象为准。
对吗？

那突然虚拟机down掉怎么办？
不就丢很多数据了吗？
对于跨多个虚拟机的分布式应用怎么办？

基本是这样, 不过 "rdb要注意与tob的数据保持一致" 这个表述不太恰当. 实际的情况是TOB在修改自己的内存数据之前, 先保证把最新数据Push给rdb. 这样即使server crash, 下次从rdb重新加载到内存的数据还是上次最后的完整数据版本.

分布式的TOB尚在计划当中, 基本的思路是实现一个分布的SwapEngine. TOB是直接通过抽象的SwapEngine接口交换物理数据的, 所以现有的分布对象数据库系统(比如MIT LCS的Thor)的模式可以作为参考来实现一个新的TOB SwapEngine, 替换目前各种EngineRDB之后可以实现分布模式. 不过这个还比较远, 纯粹的面向对象的分布式数据库系统理论尚未成熟到商业化程度.

不过TOB是为64位, 海量内存的现代硬件体系设计的, 这种体系已经向着多内核高并发的方向发展, 且已经趋于普及. 像SUN 的基于 T1 处理器的服务器, 可以同时跑 32 路硬线程, 这种环境非常适合TOB, TOB也正好能够发挥出这种架构的多CPU共享统一大内存优势.

其他一些领域用TOB的话, 高性能计算基本都是数据中心的分布模式, 所以比较合适. 大量的互联网应用也是单服务器模式, 也可以直接用TOB现在的结构.

在多台服务器需要地理分布的架构下, 这样的应用目前自己本身也要做相应的分布架构设计, 用关系数据库本身的分布方案也常常不是最好的方式, 用单机方式的关系数据库和用TOB在架构上就没有什么差别了, 设计方式都是一样的, 只不过获得的性能就天壤之别了.