openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Pflueger <Michael.Pflue...@sma.de>
Subject AW: Possibility to return detached objects from a query?
Date Fri, 12 Aug 2011 16:23:11 GMT
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.dick@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.Pflueger@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:curtisr7@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.Pflueger@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*
>

Mime
View raw message