Hibernate 中的事务性 L2 缓存
第一季度： “交易”策略保证什么？
第二季度： 以 JTA 作为事务管理器（由属性指定）的“事务”策略和“读/写”策略有什么区别？
第三季度： 如果我在 .hbm.xml 文件中为某些实体指定“事务”策略，然后使用不支持“事务”策略的 L2 缓存，该怎么办？
Q1:
What does "transactional" strategy guarantee?
Q2:
What is the difference between "transactional" strategy and "read/write" strategy with JTA as transaction manager (specified by property).
Q3:
What if I specify "transaction" strategy for some entity in a .hbm.xml file and then will use L2 cache which does not support "transaction" strategy.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于第一季度 - 根据我的理解，交易意味着两件事。如果您有同步复制，您的事务将暂停，直到所有节点都获得复制的更改。如果您有异步复制，则可以确保其他节点将看到所选隔离级别的更改（例如已提交读），并将遵守提交和角色支持。
这还意味着，如果数据库中发生错误，或者抛出另一个异常（在调用方的事务方面导致回滚），缓存也将执行更改的回滚 - 保持缓存和数据库之间的同步。
请注意，这需要 JPA 事务管理器。
对于Q2 - 读/写不是集群安全的，它不能保证节点之间的数据一致性
对于Q3 - 从未尝试过，但它可能会失败并出现一个很好的异常
For Q1 - Transactional means two things in my understanding. If you have synchronous replication, your transaction will pause until all nodes get the replicated change. if you have asynchronous replication, you can be sure that your other nodes will see the changes in the isolation level chosen (e.g. read committed) and will comply with commits and role backs.
It also means that if an error occurred in the database, or another exception thrown (causing a rollback in case of a transactional aspect on the caller) the cache will also perform a rollback to the changes - keeping a synchronization between cache and database.
note that this requires a JPA transaction manager.
For Q2 - Read/Write is not cluster safe, it doesn't guarantee data consistency between nodes
For Q3 - Never tried, but it will probably fail with a nice Exception