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.
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):
Here's a discussion about the Transfer Object pattern:
Here's a sourceforge project for building transfer objects, though I haven't used it before:
HDLCA (Hibernate Dual-Layer Cache Architecture)
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
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.
There is much more detailed discussion of these issues in th book
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,