Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Tree retrieval using eclipselink

Not sure what you mean by "more memory", if you need to have all of the
objects in memory, then they are going to take the same amount of memory no
matter how you access them.

In terms of performance, EclipseLink does provide several way to optimize
the database access to reduce the number of database calls.  You can use
either join fetching, or batch fetching.  These can be configured as query
hints, or on the mappings.

EclipseLink 2.1 also provides load groups to force instantiation of any lazy
relationships as query hints.  This will not optimize the database access,
but will avoid you having to traverse the relationships yourself.



harshavardhan786 wrote:
> 
> Hi,
> 
> We have a model like below:
> 
> A:B = 1:N ( A has 'N'   B's  ) 
> B:C = 1:N
> C:B = 1:N
> B:D = 1:N
> 
> All above are unidirectional relationships.
> 
> 
> Now there is tree/graph of objects populated . 
> We have enitity id of A. 
> 
> Can I get the whole tree/graph for which A is the root in 1
> eclipselink/JPA call ?
> 
> Currently we are traversing the whole tree, which is taking more memory .
> Are there any ways to acheive the same traversal using memory-cheap
> eclipselink/JPA calls ?
> 
> Regards,
> Harsha
> 
> 
> 


-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland 
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink 
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink , 
http://wiki.oracle.com/page/TopLink TopLink 
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink , 
http://www.nabble.com/EclipseLink-f26430.html EclipseLink 
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence 
-- 
View this message in context: http://old.nabble.com/Tree-retrieval-using-eclipselink-tp29222403p29336420.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.



Back to the top