openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Logemann ...@logemann.org>
Subject Re: slow Query (but not the SQL itself) (OpenJPA 1.2.x)
Date Fri, 04 Dec 2009 03:12:48 GMT
Hi,

i found out that some one-to-one relations in the Superclass added some heavy performance
penalties. I ve not seen it in the SQL logs though. Perhaps i missed it.
Cant comment on the detachment. It seems that its not the problem at all in my case.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 03.12.2009 um 14:53 schrieb Rick Curtis:

> Marc -
> 
> In the case where you call em.find(...) and it takes 500ms how long does
> that operation take if the result doesn't need to be detached? The reason I
> ask is that I've been doing some performance work and we found that in some
> instances we are spending way too much time detaching Entities.
> 
> -- 
> Thanks,
> Rick
> 
> On Thu, Dec 3, 2009 at 6:06 AM, Marc Logemann <li@logemann.org> wrote:
> 
>> Hi,
>> 
>> i am facing some weird performance issues. Given this  JPA Query:
>> 
>> public class SomeDao {
>>   @SuppressWarnings("unchecked")
>>   public Object getMetaData(Foo.class, long oid) {
>>       Object o = em.find(clazz, client);
>>       return o;
>>   }
>> ..
>> }
>> 
>> 
>> @Entity
>> @VersionColumn(name = "jpaversion")
>> @Table(name = "foo")
>> public class Foo extends BasicClientMetaData {
>> 
>>   @Id
>>   @Column(name = "client_oid")
>>   private long client;
>> ...
>> }
>> 
>> @MappedSuperclass
>> public class BasicClientMetaData implements MinMaxWeightAware {
>> 
>> 
>>   @Column(name = "custnr")
>>   private String customerNumber;
>> 
>>   @Column(name = "maxweight")
>>   private float maxWeightStandard;
>> ..
>> }
>> 
>> When i call the getMetaData() of SomeDao.class (which is transactional and
>> gets detached when its returned to the caller), i measured 500ms for this
>> operation. The underlying SQL only consumes 20ms which i checked by setting
>> the SQL log level to TRACE.
>> 
>> Why is there such a difference? I mean, detaching cant be such an issue
>> from performance perspective. I only have this issue with exactly these kind
>> of classes (children of BasicClientMetaData).
>> 
>> But i also have other classes which have the @MappedSuperclass which work
>> without performance problems. Does anyone have a hint where i can look out
>> for?
>> 
>> 
>> thanks.
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 
>> 


Mime
View raw message