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: Tue, 03 Nov 2015 07:52:46 +0100 Organization: Decebal Computing Lines: 74 Message-ID: <87d1vrk20x.fsf@Equus.decebal.nl> References: <87lhagkcsh.fsf@Equus.decebal.nl> <563763d9$0$23727$e4fe514c@news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="528adfd6ad074c92fdc6a7f8fb9e23d8"; logging-data="19455"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+CaQVBmmnV/lwxcVoVFgmyTMsUzlzLL4k=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Homepage: http://www.decebal.nl/ Cancel-Lock: sha1:e/V5H1tc0BUXm9w9pulmkTgaNs4= sha1:37+brRvOhNzEQHTx5dCFYeb/RMI= Xref: csiph.com comp.lang.java.programmer:32980 On Monday 2 Nov 2015 14:23 CET, silvio@internet.com wrote: > On 11/02/2015 09:47 AM, Cecil Westerhof wrote: >> We needed to change from JDBC to JPA. It looks like the performance >> is 10 to 20 times as slow as it was with JDBC. I could understand >> JPA to be slower as JDBC, but not with this kind of difference. Are >> there any common error that would explain this kind of penalty? >> > > I remember you came to us here a couple of months ago with the > intent of moving an application from JDBC to JPA. You gave us little > to go on for advice. I also remember telling you this day would > probably come... > > But let's put that aside and see if we can fix your situation. > Please tell us what the typical database access from your > application looks like and which things are particularly slow in > comparison to how it was? At the moment I am told that everything is slower. I am told that a query that took at most 5 seconds now takes one to two minutes. But I asked them to measure the old situation and until now they did not do this. I hope to get today real data about this. But several pages now give a timeout. > JDBC and JPA are incomparable. JDBC is an API to execute SQL > statements against an RDBMS (with some very limited added > abstractions to standardize access to meta-data). JPA is an object > persistence implementation that uses an RDBMS for storage (via JDBC, > btw). It has some quirky options to execute raw SQL but that is just > plain stupid. > > UNLESS you where already doing the second (persisting objects) > manually using JDBC, the performance hit after switching to JPA is > inevitable. Database access can be very quick, using JDBC or any > other library. OK, JDBC was just using rowmapper and copying the fields. No persistence at all. So maybe the difference is less strange as I thought. > But having an object persistence layer sitting between your > application and the database can make thing stupendously inefficient > for one application and it can also be a nice match with little > added overhead for the other. It just depends on what your > application is. > > Please feel free to elaborate... 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? By the way we use a generic function because a lot of classes are extended. We use: public T read(K id) { return em.find(entityClass, id); } We fill entityClass in the constructor with: entityClass = (Class) genericSuperClass.getActualTypeArguments()[0]; In the create, update and delete functions we use an em.flush beside the em.persist, em.merge and em.remove. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof