Issue Details (XML | Word | Printable)

Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: mf125085
Reporter: rahulbiswas
Votes: 1
Watchers: 1

If you were logged in you would be able to see more operations.

Running out of memory--JOINED Inheritance w/ secondary table

Created: 21/Jul/06 01:22 PM   Updated: 30/Nov/10 05:41 PM   Resolved: 24/Aug/06 02:02 PM
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: 9.1pe_dev

Time Tracking:
Not Specified

File Attachments: 1. GZip Archive src.tar.gz (3 kB) 21/Jul/06 03:42 PM - rahulbiswas


Operating System: All
Platform: All

Issuezilla Id: 860
Status Whiteboard:


Participants: marina vatkina, mf125085, Mitesh Meswani and rahulbiswas

 Description  « Hide

The application server is running out of memory doing a JPQL query. The query
loads an entity with a simple – "SELECT Object(o) from Order o where".
id is the primary key for Order.

This is happening specifically for the JOINED inheritance strategy when the base
class has a Secondary table annotation. The id being passed to the query matches
an instance of an entity derived from Order.

Running the same query for a SINGLE_TABLE strategy does not cause the same problem.

For the JOINED strategy, the appserver is doing more Full GCs which take 30-45
seconds and eventually runs out of memory. Again, the SINGLE_TABLE does not have
this issue.

A memory profile of JOINED strategy with the above query shows a large of number
of Strings, char[] and other objects being created, mostly by the jdbc driver.
It also shows a large number of
oracle.toplink.essentials.sessions.DatabaseRecord objects being created in the
fetchRow method of
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor class [which
eventually seems to be hitting the jdbc driver which creates the above String,
char[] objects.

A CPU profile shows that the fetchRow method of DatabaseAccessor is being called
a large number of times, this in turn is creating a large number of
DatabaseRecord objects.

A comparison of the CPU profile to the SINGLE_TABLE strategy shows that there is
large difference in the number of calls being made to fetchRows.

SINGLE_TABLE – 1510 invocations
JOINED – 391865 invocations

The SINGLE_TABLE profile shows that all 1510 invocations are originating from
the application used for profiling.

The JOINED profile shows that all 391865 invocations originate from
DatabaseAccessor.basicExecuteCall, but there is only one invocation of this
(basicExecuteCall) method from the application which means a large number of
data is being read from the db, which should not be the case.

So looking at the SQL generated for JOINED strategy when the base class has
Secondary table shows –

SMALLORDER t2, ORDER_SEC t1, J1Order t0 WHERE ((t0.ID = ?) AND (t1.ID = t0.ID))

Although the where clause contains the join for secondary table, it does not
contain any constraints for joining between the base entity and the derived
entities, so this is really a colossal cartesian product.

rahulbiswas added a comment - 21/Jul/06 01:22 PM

cced scott.

marina vatkina added a comment - 21/Jul/06 02:03 PM

Do you see the same behavior on 9.0pe_p48?


rahulbiswas added a comment - 21/Jul/06 02:31 PM

Yes 9.0pe_b48 also shows the same behavior.

mf125085 added a comment - 21/Jul/06 02:32 PM

Could you please attach your example to the bug report?

rahulbiswas added a comment - 21/Jul/06 03:42 PM

Created an attachment (id=331)
source for inheritance and secondary table

mf125085 added a comment - 21/Jul/06 04:50 PM


You are relying on mapping defaults for the JOINDED strategy, as there are no
inheritance related annotations in SmallOrder, MediumOrder, and LargeOrder, correct?


– markus.

rahulbiswas added a comment - 21/Jul/06 08:02 PM

Yes the derived entities use default mappings [no overrides].

mf125085 added a comment - 25/Jul/06 06:29 PM

The handling of secondary tables and JOINED inheritance strategy seem not

ExpressionQueryMechanism#buildBaseSelectionCriteria(...) sets flag
ExpressionBuilder#wasAdditionalJoinCriteria = true

then, in ExpressionBuilder#normalize(...), this flag prevents Outer Join For
Multitable Inheritance processing, which normally adds outer joins for JOINED
inheritance strategy.

Downgrading this issue to P3, as only the combination of secondary table and
JOINED inheritance strategy doesn't work.

mf125085 added a comment - 31/Jul/06 12:25 PM

Forum post

mentions a similar issue, which was also solved by my preliminary fix.

mf125085 added a comment - 03/Aug/06 12:49 PM

Fixed that some tables aren't joined in the select statement, please see:

mf125085 added a comment - 03/Aug/06 12:50 PM


marina vatkina added a comment - 03/Aug/06 12:51 PM

need to be backported

Mitesh Meswani added a comment - 24/Aug/06 02:02 PM

Changes backported to 9.0 UR1