On 17 May 2012 17:53, Andrej Golovnin <golov...@gmx.net> wrote: > Hi Steve, > >> 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. > > The question is, if you really need all LockModes for an entity. I personally > doubt it.
+1 It's definitely better to pre-create them rather than on-the-fly when they are needed, but it's a likely bet that the majority will never be used. So the problem is with these very large SQL statements... on a related anecdote, I have once seen a performance problem in which the culprit was not the amount of statements sent to the database, nor the database being too loaded, but the big sizes of the resultsets which were shipped over the wire at each request: network bottleneck. The problem was that developers had been too paranoid about the N+1 problem and were fetching everything with large JOIN FETCH statements, which had exploded the cardinality of the ResultSet because of the many redundancies (was actually a bit more complex, but you could think of ManyToOne relations repeating the "the one" side over and over). The solution was to re-introduce N+1 :-) adding then second level cache in strategical places. This is to say, I wouldn't think only about the memory cost of the bigger queries: the larger cost is likely their serialized form being transmitted to the database. Wouldn't it be very cool to define some queries as database functions? -- Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
