休眠：batch_size？二级缓存？
我有一个 Hibernate 域对象，它由应用程序的不同部分加载。有时，延迟加载每个关联是有利的，而其他关联则最好在一个连接中加载整个事物。作为我发现的一种希望令人满意的妥协：
使用批量获取，如果访问一个代理，Hibernate 可以加载多个未初始化的代理。批量抓取是惰性选择抓取策略的优化。
hibernate.default_batch_fetch_size< /代码>：
使用批量获取，Hibernate 可以加载多个未初始化的代理 如果访问一个代理。批量抓取是一种优化 惰性选择获取策略。
我还看到：
hibernate.jdbc.fetch_size：
非零值决定 JDBC 获取大小（调用 Statement.setFetchSize()）。
Hibernate 是否足够智能，可以在批量获取时查看二级缓存？即，对关联的初始调用进行一次提取，然后接下来的 X 个调用会命中缓存？这样我就可以实现我想要的延迟加载，而且还可以经常访问缓存以进行更多类似批量的事务。
如果集合的全部内容已经包含在缓存中，它仍然会在访问集合时执行获取查询吗？
谢谢。
I have a Hibernate domain object that gets loaded by different parts of the application. Sometimes it's advantageous to lazy load every association and others it's better to load the entire thing in one join. As a hopefully happy compromise I've found:
Using batch fetching, Hibernate can load several uninitialized proxies if one proxy is accessed. Batch fetching is an optimization of the lazy select fetching strategy.
hibernate.default_batch_fetch_size:
Using batch fetching, Hibernate can load several uninitialized proxies
if one proxy is accessed. Batch fetching is an optimization of the
lazy select fetching strategy.
I also see:
hibernate.jdbc.fetch_size:
A non-zero value determines the JDBC fetch size (calls Statement.setFetchSize()).
Well is Hibernate smart enough to look in the second-level cache when doing the batch fetching? i.e Do one fetch for the initial call to the association and then the next X calls hit the cache? That way I can have the lazy loading I desire but also hit the cache often for the more bulk-like transactions.
If entire contents of the collection is already contained in the cache, would it still execute the fetching queries on access of the collection?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我今天做了很多研究，并能够找到对我自己的问题的答案。我正在查看 Hibernate 代码，流程如下所示：
集合是否已初始化？
因此，如果在缓存中找到您要查找的集合中的项目，则不会发生批量提取。如果在二级缓存中未找到该项目，则会进行批量提取，但无论批量项目是否在缓存中，它都会提取批量项目。
----- 示例 1 -----
优点：（
集合中的三项 - 批量大小为 3）
第一个：
现在，在其他地方，稍后：
----- 示例 2 -----
坏处：（
集合中的三个项目 - 批量大小为 3）
在本例中，该项目索引 0 处的数据已从缓存中删除，因为缓存可能已满并且该项目已被删除，或者该项目已过时或空闲。
因此，这里的权衡是，由于批处理，您将有更少的 SQL 调用，但您会更频繁地丢失缓存。有一个打开的票证，可以在二级缓存中进行批处理，然后再将其发送到数据库。
http://opensource.atlassian.com/projects/hibernate/browse/HHH-第1775章
投票吧！
I did a lot of research today and was able to dig up a response to my own question. I was looking through the Hibernate code and the flow looks like this:
Is the collection initialized?
So if the item in the collection you're looking for IS FOUND in the cache then the batch-fetch doesn't happen. If the item IS NOT found in the second-level cache then the batch fetch happens, BUT it will do a fetch of batched items REGARDLESS of whether the batched items are in the cache.
----- EXAMPLE 1 -----
The Good:
(Three items in a collection - batch size of 3)
The first go:
Now, somewhere else, later in time:
----- EXAMPLE 2 -----
The Bad:
(Three items in a collection - batch size of 3)
In this case, the item at index 0 was removed from the cache because maybe the cache was full and the item was dropped, or the item went stale or idle.
So the trade off here is that you'll have fewer SQL calls due to batching, but you'll be missing you cache more often. There is a ticket open to have the batching look in the second-level cache before it goes out to the database.
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775
Vote it up!