• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Java Persistence API: Looking for best practice for when using FetchType.LAZY

 
P Kuling
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

To begin with I have two questions:

What's the recommended way to load LAZY attributes for use outside of session? I know you may access the LAZY fields inside the session to force loading, or use a fetch join query. Which one of these two methods do you prefer and why?

I understand it's good to have things used more seldom as LAZY, so you don't have to load these objects each time.

When should @Basic(fetch=FetchType.LAZY) be used to make String's and ints LAZY? Is it ever needed? After all the default is EAGER for these types, when should we override this default?
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"P Kuling "

Please click on the My Profile link above and change your display name to meet the JavaRanch Naming Policy of using your real first and real last names.

Thanks for your understading.

Mark
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not sure if you might be getting confused with lazy loading collections or lazy loading just some String/int value of an object.

Almost all the time I won't lazy load just a single field like an int String, etc just not really gaining anything from that except heartache when you detach your object and you get a LazyInitializationException.

On the other hand, lazy loading associations like Collections is essential to performance. Only load the collections that you need for that particular use case. So if I had an Order object with a Collection of Order Detail Lines and I am displaying a List of Orders on the results of a search screen, then I will not load the Detail Lines, they will be lazy, since the search screen doesn't need any of the detail lines.

Now when the user selects a single Order in the results page to see the details of the entire order, then in this use case I am definitely eager loading the detail lines. Maybe not all of them if the screen can only show 10 details lines, so I will incorporate paging, etc.

But that is the basics.

Mark
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic