openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Minor <davemi...@gmail.com>
Subject RE: Avoiding N+1 on collection in recursive relation
Date Thu, 24 Jul 2014 00:41:14 GMT
I got the workaround to function correctly - it was a matter of the right
query combined with the right fetch groups. Thanks!

________________________________________
From: David Minor <daveminor@gmail.com>
Sent: Tuesday, July 22, 2014 9:20 AM
To: users@openjpa.apache.org
Subject: RE: Avoiding N+1 on collection in recursive relation

Interesting - I did try your workaround and didn't see a difference, but
probably I did something incorrectly. I'll play with it some more.

For the superclass we were using @MappedSuperclass with single table
inheritance strategy. I traced through the select process in debug mode and
saw that it skipped over a number of the fields. In
JDBCStoreManager.selectSubclassMappings() there's a comment:

// select all subclass mappings that match the fetch configuration
// and whose table is in the list of those selected so far; this
// way we select the max possible without selecting any tables that
// aren't present in all possible query matches; a special case
// is made for mappings that use 2-part selects that aren't
// explicitly *not* in the default so that they can get their
// primary table data

I interpret this to mean that since we don't know the type of the subclass
in advance, we don't know if we'll need to join a particular table or not,
so only select from the ones we're already joined with.

________________________________________
From: Henno Vermeulen <henno@huizemolenaar.nl>
Sent: Tuesday, July 22, 2014 12:03 AM
To: users@openjpa.apache.org
Subject: RE: Avoiding N+1 on collection in recursive relation

First issue:
We don't use the data cache either! If I recall correctly, exactly for the
same reason: for different use cases we may use different fetch plans for
the same entity. (Actually at our client-side we have actually implement
our home-made cache - backed by ehache - that uses the fetchplan name as
part of the cache key.).

I was speaking about the entities in the persistence context. This is a
non-shared first-level cache of the EntityManager that is only kept for the
duration of one transaction. As far as I know this is always used by
default and cannot be turned off. I believe it is also used internally by
JPA. When multiple database queries are done in one transaction, JPA can
use this temporary cache to find referenced entities that have already been
loaded during the same transaction, even if you don't have shared
second-level cache turned on.

So if your performance issue is important I suggest giving my suggestion a
try!

Second issue: I haven't seen that before. Perhaps this depends on the
inheritance strategy. We have had no problems with
InheritanceType.TABLE_PER_CLASS but we have had issues with an incorrect
query being generated when using InheritanceType.JOINED so we don't use
that. Depending on your use case you may also use @MappedSuperclass which
has been working fine for us.

Regards,
Henno


--
_____________
David Minor


-- 
_____________
David Minor

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message