Java Forum

Ask Question   UnAnswered
Home » Forum » Java       RSS Feeds

Need ideas about fetching entity details in a 3-tier application

  Asked By: Carolina    Date: May 29    Category: Java    Views: 1313

Suppose we have designed a master-detail entity relation for a 3-tier application using EJB3 like this:

class BookStore{

String getName(){…}

void setName(){…}

List<Seller> getSellers(){…}

void setSellers(List<Seller> sellers){…}


class Seller{

String getName(){…}

void setName(String name){…}


Using a session bean we retrieve a list of BookStores in client side, and we are going to fetch its detail "sellers" in a lazy way and print the size of the list:

List<BookStore> bsList = sb.listAll();

if(bsList != null && bsList.size()>0){

BookStore bs1 = bsList.get(0);



After an R&D tasks we found out to use AOP and I tried AspectJ, but we insist not to compile out entity classes, and to add this ability dynamically in runtime to our classes. So I had to do it using a more direct technology about reflection called Javassist.

Regarding to your experience and knowledge, do you think it would be a good solution?

Or there could a better approach to achieve what we are going to have?

I would be so grateful in advance for your answers.



14 Answers Found

Answer #1    Answered By: Sherrie Thomas     Answered On: May 29

Which choice are you referring to ? Runtime Enhancing vs Compiling or
using AOP to solve the lazy loading problem ?

Regarding lazy loading, I prefer to handle it in a manner where the
developer knows it should reload/refresh an entity  in each app.
transaction. Dont know about your solution, so I cant comment.

Regarding bytecode enhancing vs. post-compiling, both have drawbacks.
With bytecode enhancing you'll have problems with generated classes
if you use instanceof alot, classloading problems, and sometimes buggy
implementations in libraries. With postcompilation, debugging wont be
easy because of the extra code inserted between your code. OTOH,
performance is better with compiletime weaving. Read Adrians comment
on this : dev.eclipse.org/.../msg07094.html

Unfortunately Sun hasn't provided a good  solution to intercept method
calls in java. Maybe someday we all have a unique solution  for this
problem !

Answer #2    Answered By: Anselma Schmidt     Answered On: May 29

Thanks for your direct  answer, that was almost what I was looking for, is there any more official documents or links that I can refer to, if so, I'd be grateful you or other people in this group help me to find it.

Answer #3    Answered By: Dang Tran     Answered On: May 29

Based on what you explained, I assume you have a fat client  project and you are trying to use lazy loading on the client side. There are some ORMs that have this feature. And I remember that Mr. Gavin King once addressed this issue on a thread in hibernate forum and insisted that this is not a good  design and he will never consider this to be implemented in Hibernate. I am sure you can find the discussion in Hibernate forum.

But apart from what he said, I believe that this is not a good design. Why?

Because You can justify your fetching  strategy and take away all of these complications.
Of course you can use JDK dynamic proxy, javassist or cglib to do this .Technically you are on the right track and there is no doubt about it. You can use an introduction advice using any AOP framework to do this but this is beyond the scope of a project that needs lazyloading on its client side. This is what must be done inside a framework.
And it cannot be used widely because in order to use it, a developer that just wants to load an object from database must be familiar with Aspect Oriented Patterns and restrictions, JDBC, Object Relational Mapping techniques along with Caching and this is beyond the abilities of a normal developer to be used extensively. And a framework is to facilitate problems along with hiding the complexities. This is complexity itself.
My answer is no. Never go there. Learn how to improve your fetching strategy instead...

Answer #4    Answered By: Jamie Roberts     Answered On: May 29

Based on what I explained I had been talking about a 3-tier  EJB application, not a part of client/server application  that refers to the persist layer or an ORM. Could you please tell me how to learn to fetch  a detail in a lazy way in client  side of a 3-tier application which there is no effect of an ORM like hibernate in it.

Answer #5    Answered By: Flynn Jones     Answered On: May 29

It seems to me like you have the "Session In View" problem which is not just relevant to Hibernate. It happens where people use lazyloading. If my assumption is correct, you get the lazyLoadingException when you load the detail. Is my assumption correct?

Answer #6    Answered By: Kanchan Ap     Answered On: May 29

You could use something like hibernate if lazy loading is all you need. In this special case you could also look into extra lazy loading options for collections.

Answer #7    Answered By: Haya Yoshida     Answered On: May 29

I don't know what is your target goal, there are a lot of critical items can make a solution good  or bad.
Is this a theoretical question or not ? If it is not do u make a framework or something else ? did u consider performance aspects of desired technologies or not ? r u sure about loading a collection (maybe a large collection) just to get size  of it ? don't u need to use something like extra-lazy in hibernate ( if you use hibernate as an ORM) !!!!

however i can just say you should apply proxy pattern ( even you use AOP techniques, you are applying proxy pattern indirectly)
and maybe this link can be helpful for you (to make your mind better ): http://www.hibernate.org/377.html (Remote Lazy Loading)

Answer #8    Answered By: Geneva Morris     Answered On: May 29

I forgot to introduce H3T project ( http://h3t.sourceforge.net/ )

"H3T will intercept your attempts to access uninitialized lazy elements and load them from the server for you. This will happen as seamlessly as if it were being done by Hibernate on the server."

Answer #9    Answered By: Fabia Ferrrari     Answered On: May 29

I became so confused ; if your app did not related with greater than about 10 or some more or less , why U choosed so complicated patterns ?! my main idea is not about minus or plus ur entities count ,but it is about change ur design pattern .

With respect to other friends and their answers , I think u choose hardest way to solve this problem in the world in all time . changing bytecode after it generate , cause so many future problem if U don't work on tiny app . I'm not very professional in this way but , by this reason I always took simplest way . I realize this problem in MVC design pattern , if U drop UR entities in Model project , not only is not a problem but also is a regular way to create DBMS apps . so I don't know which IDE u use to ceate this app , but i can suggest to U if U
use Oracle DB or any DB with JDBC:ODBC Bridge connection , try oracle JDeveloper .
It's very fast,Helpful and reliable spc with MVC and EJB3 .

if it's not helpful sorry to waste your time . I just wanna help you

Answer #10    Answered By: Anuja Shah     Answered On: May 29

If you dont have an answer, dont answer ! Whats it with you all
coming up saying instead use this , use that, ignoring the first
question and adding to the frustration !

You can google "Post-compile weaving Vs Load-time weaving" and find a
lot of content on this subject.

Answer #11    Answered By: Emma Campbell     Answered On: May 29

I guess you are speakin about the problem usually arise when you want to keep your objects attached in your persistence layer,
when you are moving your object from middle tier to web tier, when the object moves from your persistence layer, the lazy loding don't work any more, is this your problem?

Answer #12    Answered By: Kellie Bishop     Answered On: May 29

I strongly recommend anyone facing such problems to redesign their api and confirm it to SDO (Service Data Objects) semantics. Just follow the model SDO lays on the ground for designing such remote services which return DTO objects. H3T or any such mechanism is imho a workaround, a bad idea and will result in hard to maintain code and chatty aplications and hence bad performance.

Answer #13    Answered By: Mona Wagner     Answered On: May 29

As i told before , it is so important why someone choose this idea for retrieving object graph by the lazy association in the client-tier? Is it for researching or learning goals or not ? or just to create a phone book project and not more ?

We should be careful about its side-effects if we can't manage it well :
More round-trips [network and database] ( massive n+1 requests problems )
More marshaling and serialization latency
Data aliasing problems in the client-side
Loss of referential integrity in the client-side object graph
Less control
More restrictions
It can be an ideal conceptual solution  but it's not practical in action.

For some application  ranges (mission-critical OLTP systems) and scales it is not practical which you apply a transparent generic data loading/persisting proxy pattern for the lazy-associations of all entities, at least you need pagination as a first-class need and sometimes filtered collections (e.g snapshot of historical data) or detached on-the-fly objects without database transparent update and it seems these activities are more context-oriented.

I have just applied this pattern in the logic-layer (not the client-tier) which encapsulated into a service as a default transparent mechanism to decrease line of code and automated management to use the second level entity  cache, but it couldn't satisfied me because our services depends on data access helper technology  aspects (hibernate transparent tasks), however it has some important benefits for us and this a possible trade-off.

I believe, the transparent entity loading/persisting proxy pattern can be helpful for some cases and it can be poison for other cases or it is better to say whenever you use an ORM framework and Pojo model you should be careful, if you can't handle it well consequently you will loose the performance.

In the last project which we have developed ( integrated core banking services based on ERP concepts with more than 200 business entities and 300 tables ) i have reviewed all of mappings more than 5 times depends on usage to ensure everything is in the best way to get a better TPS.

Finally, i prefer to use passive business entities ( DTO ) in the client  side and i recommend you follow this way as a best practice if you want to control risks and you are not interested to fail your real project.

Answer #14    Answered By: Eloise Lawrence     Answered On: May 29

I am not still sure if the original poster problem was only lazy loading, but if it was:
it is nice point
database access is very slow, minimizing it has great effect on performance
so optimizing queries and relations to make sure lazy loading will not happen is best way,
but if in case some one needs lazy loading, seam framework offers a very sophisticated handling of lazy loading with hibernate or other JPA implementations.