• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Hibernate : preventing large dataloads without lazy loading

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 :-)
 
author
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The correct solution is disciplined reassociation, using Session.lock().
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 1312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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.


 
Gavin King
author
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic