The strange thing is, I ran my application in a profiler (YourKit),
and no memory is being leaked. Heap usage had just fallen to 28MB
after garbage collection when the crash occurs.

So something is amiss here. Have you heard of getting a
java.lang.OutOfMemoryError when the heap does not appear to be
exhausted, but having the error text specify that the heap is
exhausted?

-Marc

On 11/5/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
> Hi,
>
> If you are using OpenJPA's enhancer, then there should be no adverse
> memory consumption in the EM after a flush() call. In such a
> configuration, OpenJPA's incremental memory consumption is
> proportional to the number of dirty, unflushed instances in the
> transaction.
>
> The EM is automatically flushed during a commit; you can also call
> flush() yourself.
>
> -Patrick
>
> On Nov 5, 2007 8:09 AM, Marc Siegel <[EMAIL PROTECTED]> wrote:
> > Thanks for the input. I am not operating inside an explicit EJB
> > context or application server, but rather using OpenJPA in a regular
> > J2SE application as a persistence layer.
> >
> > In other words, I manage the scope of my own transactions and my
> > entityManager lifecycles.
> >
> > My transactions I understand how to scope. How should I scope the 
> > EntityManager?
> >
> > -Marc
> >
> >
> > On 11/5/07, Oliver Zeigermann <[EMAIL PROTECTED]> wrote:
> > > AFAIK in an EJB context the EM is closed when a transaction is ended.
> > > Unless you configure an extended persistence context. In that case the
> > > EM stays open even when a transaction is commited and will be closed
> > > upon removal of the EJB that holds it.
> > >
> > > Oliver
> > >
> > > 2007/11/5, Marc Siegel <[EMAIL PROTECTED]>:
> > > > Hi Folks,
> > > >
> > > > Is it necessary to close the EntityManager and open a new one to avoid
> > > > memory leaks / excessive usage? What is the best practice for
> > > > EntityManager lifecycle?
> > > >
> > > > -Marc
> > > >
> > >
> >
>
>
>
> --
> Patrick Linskey
> 202 669 5907
>

Reply via email to