openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: out of memory issues
Date Wed, 28 Jan 2009 15:51:40 GMT
Hi Jeremy,

compile-time enhancement is being used.

I figured it would have to be something like that. I just upgraded to JDK 1.6 to 
see if the enhancement provided that way is better, so fingers crossed.

Otherwise I'll have to build in the enhancement stage into the maven build and 
from what it looks like, the current way of doing that hasn't been changed since 
OpenJPA v0.9.6.


Jeremy Bauer on 28/01/09 14:35, wrote:
> Adam,
> Are you using compile time enhancement or does the web container do
> enhancement?  If not, runtime enhancement will be used and I've seen cases
> where non-agent runtime enhancement can significantly increase memory usage.
> If you aren't certain, an easy way to check is to disable runtime
> enhancement via:
>           <property name="openjpa.RuntimeUnenhancedClasses"
> value="unsupported"/>
> If your classes are not enhanced, the app will fail with an exception to
> that effect.
> -Jeremy
> On Wed, Jan 28, 2009 at 4:39 AM, Adam Hardy <>wrote:
>> Hi Mike,
>> thanks for the input.
>> The child objects are mapped entities and they total around 25 * 300, so
>> 7500.
>> This is their structure:
>>    private Long id;
>>    private BigDecimal total;
>>    private DollarReturn dollarReturn;
>>    private TestAnalysis testAnalysis;
>> where DollarReturn and TestAnalysis are also mapped entities. TestAnalysis
>> will have 7500 of these in its child list. They extend a superclass:
>>    private Long version;
>>    private Long ownerId;
>>    private Date created;
>>    private Date modified;
>> For what it's worth, they also have several transient properties.
>> I didn't get a heap dump before. Now I have changed the architecture a bit
>> to try to streamline the process, and the process doesn't crash now, it just
>> takes a very long time.
>> Regards
>> Adam
>> Michael Dick on 27/01/09 16:31, wrote:
>>> Hi Adam, just some quick thoughts,
>>> How many child objects are we talking about, and are they entities or just
>>> objects which are persisted to the database?
>>> If you have heap dumps it might be interesting to see which object(s) are
>>> taking up the most memory. It sounds like the likely culprit is the number
>>> of child objects and any OpenJPA objects associated with them.
>>> -mike
>>> On Mon, Jan 26, 2009 at 11:46 AM, Adam Hardy <
>>>> wrote:
>>>  The webapp I am working on uses OpenJPA (or Hibernate depending on bugs
>>>> blocking progress) and I have just hit a problem that currently looks
>>>> like
>>>> it will only be solved by violating the current architecture.
>>>> I'm hoping I'm wrong and thought I'd ask first.
>>>> The scenario is that the user can choose a whole range of financial
>>>> instruments to put in a portfolio, and the webapp grabs them all on
>>>> submission of the request and builds the object graph.
>>>> The Manager class which is also the transactional interface then creates
>>>> an
>>>> Analysis entity to hold performance stats, and which may create for
>>>> itself a
>>>> large number of small child objects representing past performance.
>>>> When the Analysis is done, the Manager call finishes and the transaction
>>>> commits (or I commit the transaction in my unit test), and I get an
>>>> out-of-memory exception.
>>>> Presumably it's all the child object inserts causing the problem.
>>>> Obviously I would like to do a flush before I run out of memory, but the
>>>> Analysis entity object has no access to the entity manager. Or at least
>>>> it
>>>> shouldn't have.
>>>> The other problem is that the Analysis entity can't really be saved until
>>>> the child objects are all created, so I would have to think of a dirty
>>>> work-around to allow me to save it first, to allow me to flush the child
>>>> objects.

View raw message