openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Bauer <techhu...@gmail.com>
Subject Re: out of memory issues
Date Wed, 28 Jan 2009 14:35:53 GMT
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 <adam.sql@cyberspaceroad.com>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 <adam.sql@cyberspaceroad.com
>> >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.
>>>
>>
>

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