Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Cecil Westerhof Newsgroups: comp.lang.java.programmer Subject: Re: Performance JPA Date: Wed, 04 Nov 2015 09:48:12 +0100 Organization: Decebal Computing Lines: 34 Message-ID: <87egg6i20j.fsf@Equus.decebal.nl> References: <87lhagkcsh.fsf@Equus.decebal.nl> <563763d9$0$23727$e4fe514c@news.xs4all.nl> <87d1vrk20x.fsf@Equus.decebal.nl> <56389a9e$0$23778$e4fe514c@news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="528adfd6ad074c92fdc6a7f8fb9e23d8"; logging-data="28859"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18go2bH8UufeGmWSUafK0TsFDL7GVZTJlQ=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:jBfmADwFlpdRek5xkM/ImNz9WjA= sha1:ibdrX8HtB0n27JFtum9WH30sCvU= X-Homepage: http://www.decebal.nl/ Xref: csiph.com comp.lang.java.programmer:32996 On Wednesday 4 Nov 2015 02:44 CET, Arne Vajhøj wrote: > On 11/3/2015 6:29 AM, Silvio wrote: >> On 11/03/2015 07:52 AM, Cecil Westerhof wrote: >>> As I understood it until now, there should be a little overhead, >>> but it can be worse I understand now. As said in the above >>> rowmapper was used. Now the application uses em.find to read. For >>> displaying a page only reads are done, so using em.find instead >>> rs.get... seems to make a very big difference. Is there a reason >>> for this and can there be something done about this? > >> If you look at the executed SQL you will probably see a huge amount >> of lookup-by-pk statements executed where in the past these where >> relatively rare since they where mostly multi-row selects (usually >> foreign key conditions possibly combined with other filters). >> >> This is typical for an application that has undergone a naive (in >> the one-to-one sense) port to an ORM layer. > > Really?? > > I have never seen such a problem. > > em.createQuery is easy and generate an equivalent SQL to the one > to chose if manually written. For read, create, update and delete we use find, persist, merge and remove. For the other queries mostly createQuery is used. On a few places criteria is used. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof