aspose file tools*
The moose likes Object Relational Mapping and the fly likes Hibernate : preventing large dataloads without lazy loading Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Hibernate : preventing large dataloads without lazy loading" Watch "Hibernate : preventing large dataloads without lazy loading" New topic
Author

Hibernate : preventing large dataloads without lazy loading

Mike Evans
Greenhorn

Joined: Jul 16, 2002
Posts: 8
Hi,
I am relatively new to Hibernate (brilliant software - my thanks to its creators).
Currently I am trying to have my cake and eat it - and am asking if there a pattern that would allow me to do so.
My problem is that I have two entity types - customer and contact. Each can reference any number of the other. Which means with highly cross-linked data retrieving a single customer retrieves multiple contacts which each retrieve multiple customers which each retrive... etc.
The obvious answer is lazy-loading.
However I am writing for a potentially high load client-server environment where each client request opens and closes a Hibernate session on the server. i.e. the client-server comms is stateless. In these circumstances, as I understand it, you cannot use lazy loading.
Is there a pattern that will get me around this?
Many thanks for any ideas.

Mike Evans
hernan silberman
Greenhorn

Joined: Nov 20, 2001
Posts: 27
We ran into this same problem. Instead of disabling lazy loading or otherwise crippling our Domain Object Model to make those objects work in a client/server environment, we decided to build code to send "value objects" (aka transfer objects) to the client instead of the domain objects. This adds complexity to your architecture, but it's worthwhile to study your use cases to determine if modifying your domain objects or building code to construct transfer objects makes more sense for your application.

Here's a simple example of how you might automate the building of transfer objects. Beware that this is an oversimplified example, but a worthwhile read (3 part article):
http://www.javaranch.com/newsletter/July2003/newsletterjuly2003.jsp#a5

Here's a discussion about the Transfer Object pattern:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html

Here's a sourceforge project for building transfer objects, though I haven't used it before:
http://xsnapshot.sourceforge.net/

thanks...
hernan
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
hernan thanks for the links. XSnapshot seems nice. What I consider a limitation is that you cannot provide more domain model objects as sources for the DTO.

/pope

ps: this is not intended to be count for the promotion :-)


blog - InfoQ.com
Gavin King
author
Ranch Hand

Joined: Aug 31, 2004
Posts: 76
The correct solution is disciplined reassociation, using Session.lock().


Co-Author of <a href="http://www.amazon.com/exec/obidos/ASIN/193239415X/ref=jranch-20" target="_blank" rel="nofollow">Hibernate in Action</a>
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Originally posted by Gavin King:
The correct solution is disciplined reassociation, using Session.lock().


Gavin pls can you detail this or to give a link? 10x.
somkiat puisungnoen
Ranch Hand

Joined: Jul 04, 2003
Posts: 1312

HDLCA (Hibernate Dual-Layer Cache Architecture)


Threadsafeness
Each session works with its own distinct set of persistent instances.

Non-blocking data access
Hibernate never forces threads to wait for each other (the database itself might).

Session level cache
A session-level cache resolves circular/shared references and repeated requests for the same instance in a particular session. The cache is completely safe for use in a clustered environment or where Hibernate shares access to the database with other (legacy) applications.

Optional second-level cache
Hibernate features an extremely granular (class or collection role) second-level cache. The actual cache implementation is completely pluggable and supports clustered cache solutions like Tangosol Coherence, SwarmCache, JBoss TreeCache, as well as process-level cache implementations such as EHCache and OSCache. The second-level cache is appropriate for


immutable data
mutable data in the case of exclusive database access by the Hibernate application

Optional query cache
Query result sets may be selectively cached

Works well with others
Hibernate behaves correctly in an environment where other applications have simultaneous access to the database.




SCJA,SCJP,SCWCD,SCBCD,SCEA I
Java Developer, Thailand
Gavin King
author
Ranch Hand

Joined: Aug 31, 2004
Posts: 76
http://www.hibernate.org/hib_docs/reference/en/html/manipulatingdata.html#manipulatingdata-update-lock
http://www.hibernate.org/hib_docs/reference/en/html/transactions.html#transactions-optimistic-detached


There is much more detailed discussion of these issues in th book
Mike Evans
Greenhorn

Joined: Jul 16, 2002
Posts: 8
My thanks to everyone who replied.
I have a form of DTO's through the use of lightweight 'descriptor' classes read off the same tables as the main domain objects (thanks to Hibernate's explicit polymorphism). However it does not really get over the problem that at some point I want to retrieve the domain objects proper - unless as Hernan suggests I re-architect fairly majorly.
I'll have a look at using how to combine Session.lock() across sessions with lazy loading. Looks like Gavin has made a sale ;-)

Thanks again to all,

Mike Evans
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
There is much more detailed discussion of these issues in th book


I hope it is :-). I am waiting for this book for a long time. Thanks for the links Gavin.
 
jQuery in Action, 2nd edition
 
subject: Hibernate : preventing large dataloads without lazy loading