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: Fri, 20 Nov 2015 09:09:01 +0100 Organization: Decebal Computing Lines: 54 Message-ID: <87y4dtytwi.fsf@Equus.decebal.nl> References: <87lhagkcsh.fsf@Equus.decebal.nl> <563763d9$0$23727$e4fe514c@news.xs4all.nl> <87d1vrk20x.fsf@Equus.decebal.nl> <87ziyvhs0r.fsf@Equus.decebal.nl> <87mvuui2ws.fsf@Equus.decebal.nl> <87si4e49ja.fsf@Equus.decebal.nl> <8737wc425d.fsf@Equus.decebal.nl> <87pozf3f7b.fsf@Equus.decebal.nl> <87egfu2w6a.fsf@Equus.decebal.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="10391"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX194Gj1q6/2j8BU01ldabvkoOJ953C9aFy4=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:h1t63PDVSFaSthA1pcDRGuva7dc= sha1:nYNIvNE2N2Ssu2VjlJepAT2LkK8= X-Homepage: http://www.decebal.nl/ Xref: csiph.com comp.lang.java.programmer:33148 On Saturday 14 Nov 2015 03:46 CET, Arne Vajhøj wrote: > On 11/13/2015 2:30 AM, Cecil Westerhof wrote: >> On Thursday 12 Nov 2015 07:27 CET, Cecil Westerhof wrote: >>> On Thursday 12 Nov 2015 01:10 CET, Arne Vajhøj wrote: >>>> The technique may work fine for a local database with a simple >>>> login protocol but with a remote database and complex protocol, >>>> then it could create a huge overhead. >>>> >>>> But we would need to see the rest of the persistence,xml to be >>>> sure (the standard part actually determines whether it is driver >>>> or data source). >>>> >>>> Try see: >>>> >>>> http://stackoverflow.com/questions/3526434/ibm-websphere-jpa-configuration-how-to-update-persistence-xml >>>> >>>> for an example of a persistence.xml that looks way >>>> more I would expect (no driver, data source, all managed). >>> >>> I have been trying some things, but until now without success. I >>> need to go to the office again and from there I do not have >>> newsgroup access, so some silence on my part again. I will >>> communicate my progress when I am back home. >> >> Problem solved. I removed openjpa.ConnectionDriverName and >> openjpa.jdbc.DBDictionary. > >> The performance is now comparable with the performance of JDBC. So >> I proved the naysayers wrong. > > :-) > >> OneToMany relations are also going to be implemented, so maybe the >> JPA version will be even faster as the JDBC version. ;-) > > Not necessarily faster but you may save even more code. Depending on the many side. Fetching 100 records in one swoop, should be faster as 100 records one at a time. But the cleaner code is more important. > Note that when doing this then you will need to decide on eager vs > lazy loading. At the moment they choose eager loading. Performance is good, so I doubt it will be changed, but when necessary it van be changed to lazy. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof