² 应用程序不能直接修改TimesTen CacheGroup中的表。
² 当Oracle端相应表发生更新操作,系统会通过Autorefresh交换方式更新到TimesTen中。
² 应用程序可以通过设置PassThrough属性,通过TimesTen的接口来更新Oracle中的表(TimesTen会根据PassThrough值来决定哪些SQL语句应该传递到Oracle端来操作),然后系统会通过Autorefresh交换方式更新到TimesTen中。
² 该方式可获得非常高效性能,应用程序直接访问内存中的数据,没有TCP/IP和IO带来的延迟。
² 可实现很强的扩展性,可以通过横向增加readonly CacheGroup的数量来增加系统的吞吐率(因为更新点是oracle,因此,增加cachegroup不会存在任何数据冲突问题)。
该类型cachegroup能提供很高的响应速度和吞吐率,可以有效地减少后台Oracle数据库的读取压力,但是更新需要在oracle端操作(尽管可以通过passthrough方式在timesten上操作,实际上也是在操作oracle后,然后自动更新到timesten端),适用于大量且频繁读,更新不多的数据,比如:用户信息,字典表等
² 可以直接更新CacheGroup,TimesTen再同步更新到Oracle后才更新TimesTen。
² Oracle数据通过manually loaded 或者 refreshed 方式传递到TimesTen。
² 应用程序提交一个更新请求,必须等更新Oracle和TimesTen后才返回,继续其他的交易,如果更新Oracle失败,TimesTen的交易必须回滚,如果更新TimesTen失败,应用会收到一个失败代码,这样,需要通过应用程序调用ttCachePropagateFlagSet来回滚Oracle端的交易,以保证两边的数据一致性。
² 不能在定义的时候使用Where语句(load数据可以使用Where,因此,不需要定义Where语句)。
² 不允许使用手工flush操作(数据必须是同步更新到Oracle的)。
² 同样可以使用passthrough特性。
² Truncate table不会传递到Oracle端。
该类型cachegroup能够提供很好的事务完整性,当应用获得成功返回的时候,它能保证数据在timesten和oracle中都同时存在,但是,牺牲了性能,本场景主要用于对事务要求非常高的数据场景,比如:电信客户余额信息,要求数据在timesten和oracle端同时更新。
² 可以直接更新CacheGroup,TimesTen通过replication agent将数据批量propagate到oracle数据库中。
² Oracle数据通过manually loaded 或者 refreshed 方式传递到TimesTen。
² 应用不需要等待oracle返回的结果,继续后面的交易。
² 采用这种方式,即使oracle异常当机,应用仍然可以继续工作,等oracle起来后,TimesTen会将更新自动同步到oracle上去。
该类型cachegroup能够提供很好响应速度和吞吐率,能有效减少后台oracle的读写压力,属于常用的cachegroup类型,同时用户可以通过时间清理(time-based aging)技术来实现滑动窗口场景,即旧的数据删除,新的数据被增加,从而实现Cache Group中的数据是最有效的数据(比如存储当天的航班信息,不是当天的信息让系统自动删除,oracle端不会删除),这样,保证了TimesTen中的数据始终是操作比较频繁的热数据。
² 在这种cachegroup中,用户可以通过设置AUTOREFRESH 和 PROPAGATE属性来实现自动双向更新,只有这种类型的cachegroup能同时实现双向更新,但是,数据的冲突问题必须用户在应用设计的时候避免。
² 这种方式比较灵活,无论timesten到oracle,还是oracle到timesten,用户都可以定制传输方式,试用于高级用户。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/11202013/viewspace-465881/ ,如需转载,请注明出处,否则将追究法律责任。