<quote> >> Deferring initialization of these batch loaders is one option, but that just really delays the memory consumption. Personally, if it were my app I'd rather that sizing be done up front rather than over the course of the next few hours or weeks as the system continues to run. </quote>
Not sure how that is advocating that we delay the generation ;) Anyway, that email thread is what led me to add the different batch modes. That helps with the memory consumption (I think - I was waiting on someone to test it). Have you tried one of the alternative batch modes? I think DYNAMIC is the only one that will improve memory usage, however it incurs the overhead of calculating the SQL each and every time. I have always had the idea to come back and delay the creation of these. IMO we could calculate the most likely used Loaders up-front (LockMode.NONE, LockMode.READ) and delay the more less-used ones. I think this is part of the solution. I think the bigger solution is along the lines of what Guillaume is planning on looking at. In fact this is one of the design aspects of 6.0. Loader is designed to bind the SQL and the "load plan" into one representation. The problem here is that it is designed to do this by doing both tasks internally - it templates building the SQL via its JoinWalkers, which also builds the "load plan". So both happen at the same time as part of the same process. The real solution is to break this up so that generation of the SQL and determination of the "load plan" can be separate operations - namely so that we can share the "load plan" graph with all of the nested loaders for a given batch loader (sharing the load plan across all batch loaders for a given entity is not feasible - some different fetch grapghs. Anyway, like I said - this is one of the design goals with 6.0 and is actually already in place there. I think ultimately a combination of delayed (and then cached) generation of these <things responsible for loading> and separately creatable and passable "load plans" (especially in combination with batch strategies) is the ultimate solution. I'm just not sure how feasible the "separately creatable and passable load plans" portion is in 5.x. Hopefully Guillaume has luck solving that one. On Tue, May 8, 2018 at 7:27 AM Andrej Golovnin <andrej.golov...@gmail.com> wrote: > Hi Sanne, > > > sounds great. Do you plan to contribute your updated patch version? > > I don't think it is needed. I'm sure Guillaume will provide a good > solution. And if not, then I will still have the best Hibernate > version ever. :-) (OK, I will have in any case the best Hibernate > version ever because I have more patches. But this is another story. > :-) ) > > Best regards, > Andrej Golovnin > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
