-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: [SOLVED] Realization of Lazy Loading
PostPosted: Wed Sep 21, 2011 12:08 pm 
Newbie

Joined: Wed Sep 21, 2011 12:06 pm
Posts: 3
Hello together,

i'm an apprentice for application developement und currently working at my project.
It's a Persistence Framework on Java. So after working with Hibernate in the past, i was wondering how
Hibernate is exacly implementing lazy loading.


Normally when you define a getter in a dataclass, you would just put the "FetchType.LAZY" Annotation over it and you would be good to go.
But how is this working in detail? The getter would return the value from the attribute witch would be null at this point, since it's loaded subsequent. So Hibernate has to somehow monitor the getter of my dataclass. When it got called, it must somehow trigger a methode of it's own to load the requested attribute.

After some reseach i found the library "cglib", which was used bevor by Hibernate. And after that the currently used library "javassist". This two librarys allow to modifiy the written bytecode of a class and inject your own source code before some existing source code in a method.

Well, sounds simple enough, doesn't it? Well, actually it's not. Classes that you rewrite first take effect after you reload the jvm. You can't just change something in the method and it would take effect at runtime, since the jvm doesn't normally allow the reloading of a class file that is already loaded into it. The only way to reach this, is to deploy a "hot swap", which feels troublesome and is connected to passing special parameters to the jvm.

Since Hibernate doesn't require those parameters to run, it can't be the way their doing it. Well, you can actually too just rewrite the class file, and make new instances from the modified class object you receive after modifing the class with the framework. But this doesn't look like the way they do it either, since it would require you to exchange the object the user passed to Hibernate with your created object.

Long talk, short story: I would love to know how they do it. If anyone has any knowledge of how this works, i would greatly appreciate it, if you share it.


Thanks in advance for any reply!


PS: Sorry, if my english isn't the best, i'm not an native english speaker

Regards Taorn


Last edited by Taorn on Wed Sep 28, 2011 7:27 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Realization of Lazy Loading
PostPosted: Wed Sep 28, 2011 4:40 am 
Newbie

Joined: Wed Sep 21, 2011 12:06 pm
Posts: 3
*push*


Top
 Profile  
 
 Post subject: Re: Realization of Lazy Loading
PostPosted: Wed Sep 28, 2011 5:03 am 
Expert
Expert

Joined: Wed Mar 03, 2004 6:35 am
Posts: 1240
Location: Lund, Sweden
Note the following information from the Hibernate documentation:

Quote:
Lazy property loading requires buildtime bytecode instrumentation.


In other words, this is something that is done at the same time the code is compiled, for example with an ant task.


Top
 Profile  
 
 Post subject: Re: Realization of Lazy Loading
PostPosted: Wed Sep 28, 2011 7:26 am 
Newbie

Joined: Wed Sep 21, 2011 12:06 pm
Posts: 3
Thank you, this was the impulse i needed. :)
For some reason, i didn't thought something like that would be explained in the documentation.

Problem solved.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.