tag:blogger.com,1999:blog-427258967255390991.post4645229799846528005..comments2024-03-01T16:24:46.081+08:00Comments on The Tech Faucet: JPA2 is very inflexible with eager/lazy fetchingCraig Ringerhttp://www.blogger.com/profile/02343803844223399065noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-427258967255390991.post-6158415921094976382012-12-19T20:40:16.281+08:002012-12-19T20:40:16.281+08:00@Randy I have a similar experience with large ente...@Randy I have a similar experience with large enterprise application. In one of my previous projects we ran into performance issues [which was evident from the projected database sizes being in TB's]. Since we did not have control over the stack we used JPA and tried every bit to optimize for performance but soon hit the wall.<br /><br />Thanks for the article. Nicely done.Shirish Pandharikarhttps://www.blogger.com/profile/08711504385122792110noreply@blogger.comtag:blogger.com,1999:blog-427258967255390991.post-48374479629046653082012-11-16T20:54:29.612+08:002012-11-16T20:54:29.612+08:00Another amen from me! In the ideal world we could ...Another amen from me! In the ideal world we could specify which fields should be selected and let JPA figure out how to do this efficiently without N+1 selects, perhaps providing some hints here and there for join/subselect/batch select (in the even more ideal JPA could automatically determine the best strategy).<br /><br />In my case I also have a Customer object and a Reservation object with different use cases that need to fetch different parts of the object graph. OpenJPA has already done a great job with FetchPlans that can be created on a use case basis. EclipseLink now also has similar features and Hibernate has fetch profiles.<br /><br />I feel that all of the JPA implementations are only a few steps away from this ideal, but reaching it somehow this doesn't seem to be of high priority for them.<br /><br />To illustrate: suppose we have an eager bidirectional Order @ManyToOne Customer and we wish to select orders by date (i.e. we also fetch their customer and are interested in all orders of these customers).<br /> - OpenJPA uses an N+1 select for customer.orders for each order in the query. It makes it's own decisions on the fetch strategy, this is not configurable. (https://issues.apache.org/jira/browse/OPENJPA-2296)<br /> - Hibernate: can be solved by annotating customer.order using @Fetch(FetchMode.SUBSELECT) or @BatchSize. However these strategies are not yet available for fetch profiles (https://hibernate.onjira.com/browse/HHH-4048).<br /> - EclipseLink has a similar annotation but this doesn't work for bidirectional (please correct me if I'm wrong).Henno Vermeulenhttps://www.blogger.com/profile/02554767660545897675noreply@blogger.comtag:blogger.com,1999:blog-427258967255390991.post-16684947745227040692012-11-08T00:41:06.787+08:002012-11-08T00:41:06.787+08:00Amen, brother. I am on my 3rd project using JPA a...Amen, brother. I am on my 3rd project using JPA and struggling with it on a daily basis for doing common operations, precisely due to the problems that you highlight. The situation where you have A ->> B -> C and need to fetch A is very common and by default JPA can issue hundreds of queries, killing performance.<br /><br />This is such an obvious problem that I have searched in vain for good support in either the JPA spec or in the individual implementations, but surprisingly it does not seem well addressed. EclipseLink is beginning to add features that help such as query hints and dynamically configurable entities, but the basic problem that the out-of-the-box functionality is not performant is really egregious.<br /><br />I ask interview candidates who say they have worked on a JPA project if they have had any performance problems and what did they do about them, but I rarely get good answers. I think a lot of people are working on toy databases without enough data to matter, and/or don't have very high performance goals. I work primarily in enterprise software where hundreds of tables and hundreds of thousands of rows of data are the norm, and trying to use JPA is a constant struggle of case-by-case workarounds. On one project we finally just ripped Hibernate out of the system and replaced it with JDBC and stored procedures so that we could have better control over the querying.<br /><br />I am not sure why this is not an urgent issue in the JPA community, because I believe the technology is essentially unusable for anything but the smallest of systems.Anonymoushttps://www.blogger.com/profile/06372900391942331791noreply@blogger.comtag:blogger.com,1999:blog-427258967255390991.post-64731935779815197422012-10-24T21:37:14.416+08:002012-10-24T21:37:14.416+08:00Thanks for the post, I believe you hit the nail ri...Thanks for the post, I believe you hit the nail right on the head. I am facing similar problems and am turning to native SQL since the performance on queries is horrible with JPA (because of lazy-loaded entities). Next stop NoSQL databases.Peter Haldbækhttps://www.blogger.com/profile/09608876510594329884noreply@blogger.comtag:blogger.com,1999:blog-427258967255390991.post-1813647091384537452012-08-07T11:13:11.207+08:002012-08-07T11:13:11.207+08:00Thanks Pinaki. I've been using similar facilit...Thanks Pinaki. I've been using similar facilities in EclipseLink for a while now. I haven't had any occasion to use OpenJPA yet, so I didn't realise it had similar features. Thanks.<br /><br />I had a quick look at the OpenJPA FAQ (http://openjpa.apache.org/faq.html) but didn't see any sort of "Why OpenJPA?" entry. Maybe it's worth adding something like that, noting some of the pluses and minuses of OpenJPA for people trying to select persistence providers.Craig Ringerhttps://www.blogger.com/profile/02343803844223399065noreply@blogger.comtag:blogger.com,1999:blog-427258967255390991.post-32515449843187060222012-08-07T00:53:23.890+08:002012-08-07T00:53:23.890+08:00Your concern for lack of configurability in access...Your concern for lack of configurability in access pattern within JPA is a valid one. JPA has not properly adressed the real life scenrio where access graph of a root object can vary per use case/instance basis. Both FETCH JOIN and LAZY/EAGER fetch type have obvious limitatios.<br /><br />It may be useful to learn about advanced supprt for configurable FetchPlan which can cater to your need [1]. <br />You are welcome to post further queries in OpenJPA mailing list [2], if you want to explore FetchPlan support in OpenJPA.<br /><br />Regards --<br /><br />Pinaki Poddar<br />Chair, Apache OpenJPA Project <br />http://openjpa.apache.org<br /><br />[1] http://openjpa.apache.org/docs/latest/ref_guide_fetch.html<br />[2] http://openjpa.208410.n2.nabble.com/Pinaki Poddarhttps://www.blogger.com/profile/16073196638530017268noreply@blogger.com