Using an exposed domain model - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 301

In this design, the domain model service retrieves and updates objects within a
transaction. After the transaction commits, the presentation tier navigates the
object's graph, which can cause other objects to be loaded lazily. In order for this
to work, the persistence framework must support what are called nontransac-
tional reads.
Loading persistent objects outside of a transaction
One key assumption of this design is that the persistence framework allows an
application to access persistent objects outside of a transaction, which are also
known as nontransactional reads. For example, when a JSP page generates the
HTML to display a PendingOrder , it must access the pending order's fields and
traverse relationships to other objects, such as its line items. Because the Transac-
tionInterceptor committed the transaction when the PlaceOrderService
returned, the persistence framework must allow the JSP page to access the domain
objects outside of the transaction, lazily loading them, if necessary.
Nontransactional reads are an optional JDO feature that is supported by most
JDO implementations. When nontransactional reads are enabled, the application
can perform queries and navigations outside of a transaction. The JDO implemen-
tation accesses the database using short database transactions and caches the object
graph so that subsequent field accesses and navigations are fast. An application
enables nontransactional reads by either creating a PersistenceManagerFactory
with the javax.jdo.option.NontransactionalRead property set to true or calling
setNontransactionalRead(true) on the PersistenceManagerFactory or the Trans-
action interface.
Hibernate also supports nontransactional reads. A Hibernate application can
perform queries and navigations without beginning a transaction. Hibernate will
retrieve objects from the database and cache them. No special configuration is
necessary.
Using JTA transactions
This approach works with local JDO and Hibernate transactions. Moreover, a
Hibernate application can use JTA transactions because Spring ensures that the
Hibernate Session participates in the transaction. Spring arranges for any newly
created or updated objects in the Hibernate Session to be written back to the
database before the JTA transaction commit. Unfortunately, Spring does not offer
a similar feature for JDO . A JDO PersistenceManager can only participate in a JTA
transaction if it is opened when the transaction is active. This means that a JDO
application that uses JTA transactions must use a POJO façade.