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* >
