The below code gives you the basic method to retrieve paginated results from a table for a given page, with a page capacity:

public List fetchRecordsForPage(Integer pageIndex, Integer pageSize)
{
   Query query = entityManager.createQuery("select record from DisplayRecord record order by record.id");
   //Specify where to start from
   query.setFirstResult((pageIndex==1)?0:(pageIndex-1)*pageSize);
  //Specify how much records to hold back
  query.setMaxResults(pageSize);
  return query.getResultList();
}

This can be extended to hold criteria based API in Hibernate as well.

1) Define the caching strategy on both the associated entity objects along the association chain.
2) Deactivate the lazy-loading on the association link. One has to be selective in choosing association links for deactivating lazy loading.
3) Define the caching strategy on the association link.

a) Associated with a Hibernate Session (transaction scoped) and this cache is used by Hibernate transparently. Hibernate requires a key to load object from the session cache. Hence its better to call a load() or get(), when the key(EntityKey) is known, rather than using a HQL query.
b) All queries (state of an entity, updates) in the cache gets flushed / committed to the database only when  Transaction context ends (i.e.) getTransaction().commit is called.
c) Always used and cannot be turned off.

2)    Second Level Cache (Application Layer)

a) Associated with a Hibernate’s SessionFactory (process scoped). Enabled by default in Hibernate 3 and uses EHCache as default cache provider.
b) The cache entries are dehydrated states of entity objects. A dehydrated state of entity refers to a key­-value  pair where key is the entity id (of the dehydrated entity) and the set of (deep copy) of attribute­values  (dehydrated entity fields) refer to the value.  Hibernate does not cache associations in a dehydrated object by default. One has to manually configured which association in a dehydratable entity to be cached.

Syntax : { id ­> { atribute1, attribute2, attribute3,{attribute41, attribute42},… } }

3)   Query cache (org.hibernate.cache.QueryCache)

a) Defines 2 cache regions : org.hibernate.cache.StandardQueryCache (stores query with parameters as cache key) and org.hibernate.cache.UpdateTimestampsCache (keeps stale query results of last results fetch). Both the cache regions are evicted when the entity related to the cacheable query is updated.

Syntax : { query,{parameters}} —> {id of cached entity}

b) A specific query results are cached, by specifying setCacheable(true) on Session’s Query handle.

(i) Query Cache structural representation is a QueryKey mapped to Object[][] (2-dimensional)  and holds majority of persistent object references. QueryKey represents query specific data such as the SQL Query text with parameters (positional/named). QueryKey representation would get deteriorated if parameters represent entity object or a deep rooted object hierarchy.

(ii) If multiple equivalents of load() is invoked,  there could potentially create multiple parameter versions of QueryKey containing equivalent duplicate entity objects exist in the cache.

Following are the patterns and practices that could be followed to fix these shortcomings:

1) Decorate org.hibernate.cache.StandardQueryCache and override the put() method to check if a canonical equivalent of a query results object already exist in the Object[][], and assign the same QueryKey if it exists. One needs to implement org.hibernate.cache.QueryCacheFactory also to plug into the Hibernate config.

2) Refactor the code to set entity’s keys as query parameters, rather than setting the entire entity object. Critreia representations should also use identifiers as parameters.

3) Write HQL queries to use identifiers in any substitutable parameters such as WHERE clause, IN clause etc.

4) Use positional parameters over named parameters as it could prevent using string pools.

5) If you are in a single JVM using in memory cache only, use hibernate.cache.use_structured_entries=false in your hibernate configuration.