Overview of persisting a domain model - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 122

because a Hibernate application typically uses a single Session and transaction per
request and a JDO application uses a single PersistenceManager and transaction
per request.
In addition to caching objects in the Hibernate Session or the JDO Persis-
tenceManager , most implementations support process-level caching, which can
often significantly improve the performance of an application. Some implementa-
tions also provide a query cache, which sometimes increases performance. Let's
see how those mechanisms work.
Process-level caching
Applications often access the same set of objects repeatedly, and so you can
improve performance by caching those objects across transactional boundaries.
Hibernate and some JDO implementations can be configured to cache objects for
longer than a single request or transaction in a process-level cache. The ORM
framework looks in the process-level cache for an object after looking in the Ses-
sion or PersistenceManager -level cache. If the object is in the process-level cache,
the ORM framework does not need to access the database, which often improves
the performance of the application significantly.
It is important to turn off eager loading for any cached objects since that
bypasses the cache and fetches them from the database. For example, if a restau-
rant was eagerly loaded with its referencing pending order, the persistence frame-
work would never look in the process-level cache for the restaurant. Using lazy
loading ensures that the persistence framework will look in the process-level cache.
There are some important issues to consider when using a process-level cache,
such as what objects to cache and how to handle updates to cached objects. The
process-level cache is typically highly configurable. You can usually control which
classes are stored in the cache, how many objects should be cached, and for how
long. It is best suited to storing frequently accessed but rarely modified objects.
For example, in the Food to Go application, restaurants, menu items, and other
restaurant-related objects are frequently accessed but rarely change; thus, it
makes sense to cache those objects in the process-level cache to avoid loading
them repeatedly from the database.
One challenge with using a process-level cache is handling updates to cached
objects. This isn't an issue if a single-server application updates the database using
the persistence framework since the framework updates the process-level cache.
There are, however, a couple of ways in which the objects in the cache can
become out of date. First, in a clustered application one cluster member can
update objects that are stored in another cluster member's cache. Second, the