Hello Rick, Thanks for responding. Yes, em.clear() is there after each transaction, memory grows and GC starts to dominate at some point and finishes with OOM. Normally I'd expect few tens of MBs to be occupied at each transaction. A second thought: I use mvel (dynamically executed java on entities) here and there's a chance it also keeps some references but did not spot it anything related to it in during profiling or dump.
The link to heap dump is here: http://www.isdc.unige.ch/Gaia/Download/heap.bin.gz It was done after traversing ~100k entities, so 100k/200->500 transactions. Not sure if it's relevant, but classA (SourceResult) is part of LRS. The class hierarchy is sth like: Catalog --LRS--> Source->TimeSeries Run --LRS-> SourceResult->TimeSeriesResult Run also references Catalog. SourceId is (CatalogId,int) TimeSeriesId is (SourceId,type) SourceResultId is (Runid,SourceId) TimeSeriesResultId is (SourceId,type) where type is smallint. SourceResult is derived from Source and references it back. SourceResult is being traversed here in batches of 200, each in separate transaction. The persistent fields of entities are not modified, only some transient ones. Bucket holds all SourceResults Ids to be traversed (~400k) -- View this message in context: http://openjpa.208410.n2.nabble.com/Memory-leak-for-long-lived-read-only-EM-tp7581554p7581564.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
