JBoss TreeCache的并发策略配置为二级Hibernate缓存
我正在使用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)
JBossTreecache
NONE
IsolationLevel
JBossTreeCache
NONE
READ_ONLY
TRANSACTIONAL
NONSTRICT_READ_WRITE
没有找到相关结果
已邀请:
1 个回复
倪蕊悲潍
但为配置为，会发生什么？ 大多数情况下，生产中难以发现的错误......您应该明白，通过使用读写缓存，您实际上已经陷入了分布式事务中的所有“细节”。 好的，关于组合： 当对象不更改时，应使用Hibernate中的只读缓存设置。例如，对于国家字典。缓存并发级别NONE或READ_ONLY应该与它一起使用。 当您的缓存对象发生变化时，应该使用非严格读写，但这种情况很少发生，竞争条件的可能性很小。例如，对于时区词典 - 时区可能偶尔出现/消失，但这种情况可能每年发生几次。同样，应该使用缓存并发级别NONE或READ_ONLY。 现在，更有趣的组合。Hibernate中的缓存不安全，Hibernate假定缓存更新是事务性的，但没有做任何事情来确保它。所以你必须使用一个完整的外部XA（分布式事务）协调器，除非你真的知道你在做什么，否则你真的真的不想要它。最有可能的是，您必须使用完整的EJB3容器来支持XA-manager，尽管可以使用http://www.atomikos.com/等外部事务管理器和普通的servlet + Spring。显然，你需要使用缓存。 'READ_WRITE`是一个有趣的组合。在这种模式下，Hibernate本身就是一个轻量级的XA协调器，所以它不需要一个完整的外部XA。它的工作原理简短说明： 在这种模式下，Hibernate管理事务本身。所有数据库操作必须在事务内，自动提交模式将不起作用。 在期间（可能在事务生存期内多次出现，但通常在提交之前发生）Hibernate会通过一个会话并搜索更新/插入/删除的对象。然后，这些对象首先保存到数据库，然后在高速缓存中锁定和更新，因此并发事务既不能更新也不能读取它们。 如果事务随后被回滚（显式或由于某些错误），则锁定的对象被简单地释放并从缓存中逐出，因此其他事务可以读取/更新它们。 如果事务成功提交，则只需释放锁定的对象，其他线程可以读/写它们。 这里有几点好处： 可能的可重复读取违规。想象一下，我们有事务A（tA）和事务B（tB）同时启动，并且加载对象X，tA然后修改此对象，然后提交tA。在许多使用快照隔离的数据库（Oracle，PostgreSQL，FireBird）中，如果tB再次请求对象X，它应该接收与事务开始时相同的对象状态。但是，READ_WRITE缓存可能违反了这种情况 - 那里没有快照隔离。 Hibernate试图通过在缓存对象上使用时间戳来解决它，但是在计时器分辨率较差的操作系统上（Windows上为15.6ms），可以保证让一些比赛漏掉。 可能的乐观陈旧对象版本 - 如果你非常不幸在Windows上工作，并且有几个事务提交具有相同的时间戳，则可能会获得过时的对象版本。