Java Reference
In-Depth Information
manager.close();
factory.close();
}
}
While the configuration of an EJB 3 application server falls well outside the scope of this
book (which is a shame, because the topic is interesting—see Pro EJB: Java Persistence API , by
Mike Keith and Merrick Schincariol (Apress, 2006), for a good introduction to the subject), the
use of an EntityManager deployed into an EJB 3 application server is straightforward. Typically
in such an environment, the container manages the EntityManager . Listing A-4 demonstrates
how to obtain a reference to an EntityManager in such an environment—only very simple
changes would be necessary in Listing A-3 to support this. Note that in this environment,
there is no need to interact with the EntityManagerFactory —the container manages the
appropriate interaction with the factory in a way that is transparent to the user code.
Listing A-4. Obtaining an EntityManager from the Container by Injection
public class Ejb3Example {
@PersistenceContext(unitName="sampleManager",type=EXTENDED)
EntityManager manager;
// …
}
As Listing A-4 demonstrates, the combination of container-managed EntityManager s, anno-
tations, and resource injection makes the acquisition of an EntityManager object trivially simple
(and remember, the EntityManager is essentially the same as a Hibernate Session object).
Hibernate provides a couple of additional features to facilitate the transition of
Hibernate 3 code to EJB 3. Where your application uses a Configuration (or an
AnnotationConfiguration ) object to programmatically configure the Hibernate application,
there is now an alternative Ejb3Configuration class that can be used in a similar manner to
provide the configuration information for the EJB 3 objects without the need for a
configuration.xml file.
The <jb3configuration> element of the Hibernate Tools Ant task conversely allows the
configuration of the tasks to be drawn from the classpath's META-INF/configuration.xml file,
instead of from an explicitly identified Hibernate configuration or properties file.
Managed Versioning and Optimistic Locking
While we have saved versioning for this appendix's discussion of advanced features, it is
actually quite straightforward to understand and apply. Consider the following scenario:
Client A loads and edits a record.
Client B loads and edits the same record.
Client A commits its edited record data.
Client B commits its differently edited record data.
While the scenario is simple, the problems it presents are not. If Client A establishes
a transaction, then Client B may not be able to load and edit the same record. Yet in a web
Search WWH ::




Custom Search