JBoss TreeCache的并发策略配置为二级Hibernate缓存

Question

我正在使用JBoss EAP 4.3.

当我使用内置的JBoss TreeCache作为Hibernate的二级缓存时,我正在研究并发策略的不同选项.我已经设置好了,我已经通过查看日志验证了缓存是否正常工作,但我不确定实际使用的是什么并发策略以及它是如何工作的.

对于每一个实体,我可以设置下面的"用法"的价值观之一,在@Cache注释:NONE,READ_ONLY,NONSTRICT_READ_WRITE,READ_WRITE,TRANSACTIONAL.

在另一方面,在我的JBossTreeCache配置文件,我可以设置IsolationLevel为整个高速缓存执行下列操作之一:NONE,READ_UNCOMMITTED,READ_COMMITTED,REPEATABLE_READ,SERIALIZABLE(或者只是使用OPTIMISTIC).

在一次查看配置选项时,文档非常清楚,但我想知道当您组合不同选项时会发生什么.

例如,如果你设置@Cache(usage = CacheConcurrencyStrategy.TRANSACTIONAL)一个实体,但配置NONE为IsolationLevel为JBossTreecache,会发生什么？

我也相信,JBossTreeCache只有支持NONE,READ_ONLY以及TRANSACTIONAL使用情况,但什么IsolationLevel是你允许他们结合？如果您使用例如会发生什么NONSTRICT_READ_WRITE？

总而言之,这里应该有5x6种不同的组合,但并非所有组合都有意义.

anyoone可以帮我整理一下吗？

Answer 1

隔离级别是一个棘手的问题.

例如,如果你设置@Cache(usage = CacheConcurrencyStrategy.TRANSACTIONAL)一个实体,但配置NONE为IsolationLevel为JBossTreecache,会发生什么？

大多数情况下,生产中难以发现的错误...您应该明白,通过使用读写缓存,您实际上可以在分布式事务中使用所有"细节".

好的,关于组合:当你的对象没有改变时,应该使用Hibernate中的只读缓存设置.例如,对于国家字典.缓存并发级别NONE或READ_ONLY应该与它一起使用.

当您的缓存对象发生变化时,应该使用非严格读写,但这种情况很少发生,竞争条件的可能性很小.例如,对于时区词典 - 时区可能偶尔出现/消失,但这种情况可能每年发生几次.同样,应该使用缓存并发级别NONE或READ_ONLY.

现在,更有趣的组合.

TransactionalHibernate中的缓存不安全,Hibernate假定缓存更新是事务性的,但没有做任何事情来确保它.所以你必须使用一个完整的外部XA(分布式事务)协调器,除非你真的知道你在做什么,否则你真的真的不想要它.最有可能的是,您必须使用完整的EJB3容器来支持XA-manager,尽管可以使用http://www.atomikos.com/等外部事务管理器和普通的servlet + Spring.显然,您需要使用TRANSACTIONAL缓存.

'READ_WRITE`是一个有趣的组合.在这种模式下,Hibernate本身就是一个轻量级的XA协调器,所以它不需要一个完整的外部XA.它的工作原理简短说明:

1. 在这种模式下,Hibernate管理事务本身.所有数据库操作必须在事务内,自动提交模式将不起作用.
2. 在flush()(在事务生命周期中可能出现多次,但通常在提交之前发生)Hibernate会通过一个会话并搜索更新/插入/删除的对象.然后,这些对象首先保存到数据库,然后在高速缓存中锁定和更新,因此并发事务既不能更新也不能读取它们.
3. 如果事务随后被回滚(显式或由于某些错误),则锁定的对象被简单地释放并从缓存中逐出,因此其他事务可以读取/更新它们.
4. 如果事务成功提交,则只需释放锁定的对象,其他线程可以读/写它们.

这里有几点好处:

可能的可重复读取违规.想象一下,我们有事务A(tA)和事务B(tB)同时启动,并且加载对象X,tA然后修改此对象,然后提交tA.在许多使用快照隔离的数据库(Oracle,PostgreSQL,FireBird)中,如果tB再次请求对象X,它应该接收与事务开始时相同的对象状态.但是,READ_WRITE缓存可能违反了这种情况 - 那里没有快照隔离.Hibernate试图通过在缓存对象上使用时间戳来解决它,但是在计时器分辨率较差的操作系统上(Windows上为15.6ms),可以保证让一些比赛漏掉.

可能的乐观陈旧对象版本 - 如果你非常不幸在Windows上工作,并且有几个事务提交具有相同的时间戳,则可能会获得过时的对象版本.