openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Curtis <curti...@gmail.com>
Subject Re: problems traversing large result sets
Date Wed, 03 Aug 2011 14:15:18 GMT
What version of OpenJPA are you using?

On Wed, Aug 3, 2011 at 2:59 AM, Michael Pflueger <Michael.Pflueger@sma.de>wrote:

> Hi,
>
> Can anyone of you give a hint about traversing huge result sets using
> OpenJPA?
>
> I've tried enabling large/scrolling result sets by setting FetchBatchSize.
> However, when I iterate over the result, I need to repeatedly call
> entityManager.clear(), because a simple entityManager.detach(object) after
> each access is not enough to clean old objects from the heap and thus I get
> OutOfMemory erros without the clean().
>
> entitymanager.clean()  seems to work fine without large result sets
> enabled.
> With LRS enabled, however, I get a problem during the traversal, because
> after a clean() call the iterator delivers an object that openjpa thinks is
> managed, but the object contains a lazy one to many relation and I can't
> access it, I get a nullpointer exception. I've tried detaching and merging
> the object I get from the iterator, but this does not help, openjpa does
> neither detach nor merge it properly so I can use the lazy association
> again.
>
> So I'm a bit puzzled about how people traverse large sets of data, and
> about why a simple detach of objects is not enough to let the garbace
> collector clean them... I have not configured any additional cache.
> I could try to provide a simple testcase if one is needed.
>
>
> Regards,
> Michael
> ___________________________________________________
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message