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, 11 Nov 2015 23:20:16 +0100 Organization: Decebal Computing Lines: 46 Message-ID: <87y4e42n6n.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> <87k2pp3x11.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="29839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bsG5VdZMfmgYS5kqyTSkJF1paYcwGUiA=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:J3Q1CWRUr7ExIcttWpuPRNKxtIo= sha1:wqPKtf3vRE8oQb3wsiD3lGffBLA= X-Homepage: http://www.decebal.nl/ Xref: csiph.com comp.lang.java.programmer:33110 On Wednesday 11 Nov 2015 15:30 CET, Arne Vajhøj wrote: > On 11/11/2015 12:50 AM, Cecil Westerhof wrote: >> On Wednesday 11 Nov 2015 01:56 CET, Arne Vajhøj wrote: >>> On 11/10/2015 2:07 AM, Cecil Westerhof wrote: >>>> In principal database logging is going to be enabled, but I am >>>> waiting already a week for this. >>> >>> If you enable logging of the generated SQL then you can start >>> moving on instead of waiting for somebody else. >> >> The problem was that logging did not work. But I understood that >> they solved the problem with that. Until know I was told to look at >> the logging of the unit tests. I do not think that you can be sure >> that unit tests will give an accurate representation of live >> behaviour. > > If the problem really is JPA generating bad SQL then I would say > that there is a pretty big chance that you will spot it already in > the unit tests. That is not the problem. I have got some data and what is happening is that JPA waits 4.5 seconds before it starts executing the database query. See my other reply. >> Something else: I do not think it could be a problem, but better >> save as sorry. I read somewhere that using @EmbeddedId could result >> in a performance hit. Is that true? If so what could be the reason >> for this? Because there are quit a few entities that use >> @EmbeddedId. > > In very pure ORM then you would have a single synthetic PK field. > > But the other should work fine as well. > > No harm done in taking a quick look at the generated SQL though > to verify that it turns out OK. That turned out not to be the problem. With @EmbeddeId and with @Id there is a pause of 4.5 seconds before the query is executed. So at the moment it looks like @EmbeddedId does not have a bearing on this. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof