hibernate何时使用各种缓存模式在二级缓存和DB之间执行同步？

Question

我一直在阅读hibernate文档，讨论二级缓存和查询缓存，并留下了关于二级缓存与DB同步的问题，反之亦然。每个会话都可以定义自己的缓存模式，比如正常、获取、放置和刷新。将2L缓存

Answer 1

大海中的一滴

说到2级缓存，直接来到

usage-指定缓存策略：事务性、读写、非严格读写或只读

在实体缓存方面，创建/更新/删除操作的预期调用序列是：

删除：

lock(java.lang.Object, java.lang.Object)
evict(java.lang.Object)
release(java.lang.Object, org.hibernate.cache.CacheConcurrencyStrategy.SoftLock)

更新：

lock(java.lang.Object, java.lang.Object)
update(java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object)
afterUpdate(java.lang.Object, java.lang.Object, java.lang.Object,org.hibernate.cache.CacheConcurrencyStrategy.SoftLock)

插入：

insert(java.lang.Object, java.lang.Object, java.lang.Object)
afterInsert(java.lang.Object, java.lang.Object, java.lang.Object)

就集合缓存而言，所有修改操作实际上只是使条目无效。此处的调用顺序为：

lock(java.lang.Object, java.lang.Object)
evict(java.lang.Object)
release(java.lang.Object, org.hibernate.cache.CacheConcurrencyStrategy.SoftLock)

每当会话启动时，都会向其添加时间戳。（ST）每当在缓存中加载项时，都会向其添加时间戳。（CT）现在如果ST

非严格读写

•永远没有锁定。

因此，当对象在数据库中实际更新时，在提交时（直到数据库完成提交），缓存有旧对象，数据库有新对象。

现在，如果任何其他会话查找对象，它将在缓存中查找并找到旧对象。（DIRTY READ）

•但是，一旦提交完成，对象将从缓存中逐出，以便查找对象的下一个会话必须在数据库中查找。

用于读写

•一旦有人试图更新/删除某个项目，该项目就会被软锁定在缓存中，因此如果任何其他会话试图查找它，它必须进入数据库。

现在，一旦更新结束并且数据已提交，缓存就会用新数据刷新并释放锁，这样其他事务现在就可以在CACHE中查看，而不必访问数据库。

总结如下：

ReadOnly缓存只能执行读取和插入，不能执行更新/删除。执行最快。

非严格读写缓存永远不会使用任何锁，因此总是有可能发生脏读。但是，它总是从缓存中逐出条目，以便任何后续的session始终引用DB。

读写缓存使用锁，但以异步方式，首先插入/更新/删除在发送中发生。当缓存项被软锁定且其他会话必须引用数据库时。发送完成后，释放锁并更新缓存。（交易之外）。在某些情况下，可能会影响可重复读取。

显然，事务缓存会更新同一事务中的数据库和缓存，因此它始终处于与数据库一致的状态。

大部分已更新的实体类型，并且具有并发的读取和更新，读写缓存策略可能不是很有用，因为大多数读取将转向数据库

查询缓存

e需要在hibernate中启用以下属性。cfg公司。xml 1

真实的

此设置创建两个新的缓存区域：

org.hibernate.cache.Standard ardQueryCache，保存缓存的查询结果

<代码>组织。冬眠隐藏物UpdateTimestampsCache，保存可查询表的最新更新的时间戳。这些用于验证查询缓存提供的结果。

查询缓存不缓存缓存中实际实体的状态；它只缓存标识符值和值类型的结果。因此，对于那些预期作为查询结果缓存的一部分进行缓存的实体，查询缓存应始终与二级缓存一起使用