openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Wolf <cwolf.a...@gmail.com>
Subject Re: What is the inverse of "lazy fetching"?
Date Tue, 08 Jan 2013 20:20:55 GMT
That might help.  I'm just concerned about the wording of the doc page:

http://openjpa.apache.org/builds/2.2.1/apache-openjpa/docs/ref_guide_pc_scos.html#ref_guide_pc_scos_proxy_custom

"Delay loading allows non-indexed add and remove operations to occur
without prior loading of the collection from the data store."

What does "non-indexed" mean?  Of course the child entities in the
collection will be getting written to an underlying table,
which will have at least one index corresponding to the primary key,
as well as possibly other indexes to improve queries.

Or is "non-indexed" referring to not traversing the collection while
adding or removing?

And are these proxies orthogonal to whether using enhanced entities or
not?  Because I thought proxied entities was a less-then-optimal
fallback mechanism to using enhanced entities?   (sorry for all the
questions - first project using JPA, any JPA)

Chris

On Tue, Jan 8, 2013 at 3:03 PM, Kevin Sutter <kwsutter@gmail.com> wrote:
> Thanks for the clarification.  Maybe the new DelayCollectionLoading [1]
> feature would help in your situation.  This allows you to add new elements
> to a collection without loading the original collection.  So, if you are
> adding items in bunches, you wouldn't have to load up the existing
> collection on each new add.
>
> This support is in OpenJPA 2.2.x [2].  Does this help your situation?
>
> Kevin
>
> [1]
> http://openjpa.apache.org/builds/latest/docs/docbook/manual.html#ref_guide_pc_scos_proxy_custom
> [2]  https://issues.apache.org/jira/browse/OPENJPA-2165
>
> On Tue, Jan 8, 2013 at 12:29 PM, Chris Wolf <cwolf.algo@gmail.com> wrote:
>
>> Hello Kevin,
>>
>> Thanks for the reply.  I am not sure if that will help or not.  So
>> referring back to my original scenario, I have many-to-one,
>> with the master object having a collection field to hold references to
>> child objects, and there could be a huge number of
>> child objects.   Ar you saying that I could create child objects in
>> batches, of say, 1000 and either do:
>> em.getTransaction().commit();  // managed
>>
>> -= or =-
>>
>> // JSE, not managed
>> em.getTransaction().commit();
>> em.clear();
>>
>> at the end of each batch?
>>
>> Will that somehow remove the committed child objects from the collection?
>>
>> I guess I would need to keep an active reference to the master object
>> to keep it active so subsequent batches of child objects
>> can be added/committed.   At this point, I'm not concerned about
>> keeping all the batches under one transaction - I just need
>> to get the millions of child records added to the DB without using
>> huge amounts of memory.  Again, kind of like the inverse of
>> "lazy fetching", but on the WRITING side.
>>
>> Thanks,
>>
>> Chris
>>
>>
>> On Tue, Jan 8, 2013 at 10:48 AM, Kevin Sutter <kwsutter@gmail.com> wrote:
>> > EntityManager.clear()
>> >
>> > In a managed, transactional environment, the persistence context is
>> cleared
>> > at the end of each transaction.  But, in a JSE mode, the persistence
>> > context is still active at the end of a transasction.  EM.clear() will
>> > clear the persistence context.  As long as you don't have any other
>> > references to these entities, they should get cleaned up by the gc.
>> >
>> > Is this what you were looking for?
>> >
>> > Kevin
>> >
>> > On Tue, Jan 8, 2013 at 9:29 AM, Chris Wolf <cwolf.algo@gmail.com> wrote:
>> >
>> >> I have a model with, say, a one-to-many relationship, where there may
>> >> be an enormous number of child records.  I see that there is thorough
>> >> documentation treatment on the subject of reading such object FROM the
>> >> database, e.g. fetch=FetchType.LAZY attr and/or @LRS (large result
>> >> set), etc.  but this seems to only optimize READING.
>> >>
>> >> My concern is how can I achieve a similar, converse, optimization when
>> >> WRITING?  i.e. inserting INTO the database.  For example, as I
>> >> understand it, once I persist the master object, (enhanced, of
>> >> course), then the collection field which keeps a set of child records
>> >> uses transitive persistence to automatically write a child record
>> >> whenever a child object is added to the collection - but here's the
>> >> thing; if I'm just doing an initial load of the master object and all
>> >> it's children, and there could be a million children - I don't want
>> >> each newly added child to stay around in memory (in the master's
>> >> collection field) once it has been persisted via transitive
>> >> persistence, otherwise I'll run out of memory.
>> >>
>> >> Is there some mechanism to have child objects be removed from memory
>> >> once persisted?
>> >>
>> >> Thanks,
>> >>
>> >> Chris
>> >>
>>

Mime
View raw message