That's very interesting. In my case, profiling with YourKit revealed that twice as much data was being stuck in the JDBC driver (SQLiteJDBC) as in the OpenJPA driver.
By doing self-contained data access in transactions, and by completely discarding and recreating the EntityManager every so often as well as the EntityManagerFactory, I seem to have held memory usage down pretty well. I don't know if that strategy would work in your case but I would keep it in mind, apparently the J2EE application servers do this? -Marc On 11/6/07, Christiaan <[EMAIL PROTECTED]> wrote: > > Hi, > please note that flush() has not the same memory usage characteristics as a > commit() has, as mentioned in thread: > http://www.nabble.com/flush%28%29%3A-memory---performance-tf4434606.html > > However, it is not clearly described in the spec how this should be handled, > so I've added a request for this at: > http://mail-archives.apache.org/mod_mbox/db-jdo-user/200709.mbox/[EMAIL > PROTECTED] > > please add your vote;-) > > kind regards, > Christiaan > > > Patrick Linskey-2 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 > > > > -- > View this message in context: > http://www.nabble.com/EntityManager-memory-usage-tf4752283.html#a13605071 > Sent from the OpenJPA Users mailing list archive at Nabble.com. > >
