Collections (i.e. @OneToMany and @ManyToMany) are by default loaded lazily, which means the data is not retrieved from the database until it's used. For example, suppose Account-Customer is many-to-one and the Customer class is like the following:

When you use customerDao.getCustomer() to load a Customer object, the accounts field is actually not initialized. It will remain uninitialized unless you call customer.getAccounts(), at which point the ORM will automatically sends anther query to the database and return the data.

Lazy loading is important for performance (otherwise you may load the whole database when you just want one object), so most of the time you should keep the default behavior. There are a couple of potential pitfalls though:

• Lazy loading only works if you access the field using a getter, e.g. customer.getAccounts(). In other words, direct field access like customer.accounts won't work (or at least won't work without some additional AOP support).
• Lazy loading only works if the object is managed by an entity manager. This is easy to understand - without an entity manager there's no automatically data retrieval.

The second point can get tricky when you use session attributes. The problem is that after a request is processed, the entity manager associated with that request is closed (you can think of it like closing a database connection after the request processing is done), and any objects saved in the session scope are no longer managed by an entity manager. Such objects are called detached objects, and you'll get an error if you try to do lazy loading on a detached object. There are two solutions for this: use FetchType.EAGER in @OneToMany or @ManyToMany to load the collection when the owning object is loaded, or re-attach the detached object to an entity manager with a merge() (and remember the re-attached object is the one returned by merge(), not the one passed to merge()).

That's what cascade type is for (see the Hibernate lecture notes). For example, if you specify cascade type to be CascadeType.MERGE, when you save (i.e. merge) a Customer object, all the new/modified accounts of the customer will be saved too. And in this case, if Account has a Customer reference, you should do account.setCustomer(customer) before doing customerDao.saveCustomer(customer).

It doesn't matter whether you use AccountDao or CustomerDao (with cascade) to save accounts. I'll go with whichever that is more "natural" and/or convenient.