....I knew this sounded familiar. It looks like I found this problem quite a while back and haven't got around to fixing the bug.
https://issues.apache.org/jira/browse/OPENJPA-1672 On Fri, Aug 12, 2011 at 11:23 AM, Michael Pflueger <michael.pflue...@sma.de>wrote: > Seems that would be 1.0 then. > > See my other post containing a testcase/src folder including a > persistence.xml. > > I hope this helps reproducing the problem. > > Michael > > -----Ursprüngliche Nachricht----- > Von: Michael Dick [mailto:michael.d.d...@gmail.com] > Gesendet: Freitag, 12. August 2011 18:04 > An: users@openjpa.apache.org > Betreff: Re: Possibility to return detached objects from a query? > > Some of the detach behavior depends on the version in your persistence.xml > file. It's kind of a shot in the dark, but are you validating against > version 2.0, or 1.0? > > -mike > > On Fri, Aug 12, 2011 at 9:56 AM, Michael Pflueger > <michael.pflue...@sma.de>wrote: > > > Hi Rick, > > > > Yes, I'm using 2.2 trunk, ~1 week old. > > > > I did try LRS in the past, but as I encountered a bug there I switched > away > > from it. > > This bug seems to be fixed in trunk, but I could only use LRS for > Importing > > data anyway, as our main DB is MySQL, which lacks proper LRS support with > > concurrent queries. > > > > Thus, I wrote a simple query chunker which loads a chunk of results from > > the db, provides an iterator, and upon reaching the end automatically > loads > > the next chunk, etc. > > > > So, I could try LRS for the purpose of debugging etc, but it should work > > without them aswell. > > > > And Yes! After a quick check, with CopyOnDetach=false, OpenJPA behaves as > > expected and does not use more than about 30MB of Heap space and most > > importantly stays in that range. (as long as I detach my entities :) > > > > Thanks! > > > > I'd still be interested whether it's a bug in the copyOnDetach=true > > codepath or if it is working as designed that the manager keeps managed > > copies on detachment? > > > > -----Ursprüngliche Nachricht----- > > Von: Rick Curtis [mailto:curti...@gmail.com] > > Gesendet: Donnerstag, 11. August 2011 16:11 > > An: users@openjpa.apache.org > > Betreff: Re: Possibility to return detached objects from a query? > > > > Michael - > > > > > While I still wonder about why detaching my entities doesn't reduce my > > heap memory usage > > You didn't mention what level of code you are running on, but if it is > > > 2.0, it might be a bug. Try setting the following property: <property > > name="openjpa.Compatibility" value="CopyOnDetach=false"/> > > > > > also wonder whether there is a possibility for a query to return > detached > > objects in the first place? > > I'm not aware of one. That doesn't mean the capability doesn't exist, I'm > > just not aware of it :) > > > > > Calling detach() for every object looks to be rather expensive > > Correct, in some of our performance testing we have found that detach is > > quite expensive. I put in a property LiteAutoDetach which is in place to > > quickly detach the entire persistence context, but unfortunately this > > optimization isn't available for detaching single instances. > > > > I know I missed an email you sent to this list a number of days ago where > > you were asking a very similar question. I don't want to derail this > > thread, > > but have you looked at large result sets[1]? The might simplify some of > > your > > loading code. > > > > > > [1] > > > > > http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_dbsetup_lrs > > > > Thanks, > > Rick > > > > On Thu, Aug 11, 2011 at 2:06 AM, Michael Pflueger > > <michael.pflue...@sma.de>wrote: > > > > > Hi, > > > > > > While I still wonder about why detaching my entities doesn't reduce my > > heap > > > memory usage, > > > I also wonder whether there is a possibility for a query to return > > detached > > > objects in the first place? > > > This might be quite efficient for scenarios where you need to read lots > > of > > > data but not update it or need any other features of a managed entity. > > > Calling detach() for every object looks to be rather expensive, and > above > > > method would not only avoid that but could possibly avoid some > attachment > > > overhead aswell. > > > ___________________________________________________ > > > > > > SMA Solar Technology AG > > > Aufsichtsrat: Guenther Cramer (Vorsitzender) > > > Vorstand: Juergen Dolle, Roland Grebe, Uwe Hertel, Pierre-Pascal Urbon, > > > Marko Werner > > > Handelsregister: Amtsgericht Kassel HRB 3972 > > > Sitz der Gesellschaft: 34266 Niestetal > > > USt-ID-Nr. DE 113 08 59 54 > > > WEEE-Reg.-Nr. DE 95881150 > > > ___________________________________________________ > > > > > > > > > > > > -- > > *Rick Curtis* > > > -- *Rick Curtis*