Object Relational Mapping and JPA - Introducing Java EE 7 - page 70

stored procedure invocation must be registered using the registerStoredProcedureParameter method, rather
than the StoredProcedureQuery interface. The following code shows how to call the CREATE_EMP stored procedure
dynamically:

StoredProcedureQuery qry = em.createStoredProcedureQuery("CREATE_EMP");
qry.registerStoredProcedureParameter("FIRSTNAME", firstName);
qry.registerStoredProcedureParameter("LASTNAME", lastName);
qry.registerStoredProcedureParameter(“STATUS”, status);
qry.executeUpdate();

■ Utiliztion of database stored procedures can be beneficial because they allow for separation between the
compiled java code and the database procedure. that is, if a database stored procedure implementation needs to
change, it can be adjusted without redeploying the java application, so long as the procedure name or number of
parameters stays the same.

Note

Synchronization of Persistence Contexts
By default, persistence contexts are synchronized, meaning that the context is automatically joined to the current JTA
transaction, and that any updates that are made are propagated accordingly. In JPA 2.1, a persistence context can
be specified as unsynchronized, meaning that it be not enlisted in any JTA transaction unless explicitly joined to
a transaction by the application. One may wish to create an entity manager as unsynchronized if an application
needed to perform work against Entity classes, without having the changes flushed to the database until the work
was complete. To create an unsynchronized persistence context, specify a synchronization attribute of type
SynchronizationType.UNSYNCHRONIZED . The following demonstrates how to create such a persistence context:

@PersistenceContext(synchronization=SynchronizationType.UNSYNCHRONIZED) EntityManager em;

To join an unsynchronized persistence context to a JTA transaction, invoke the EntityManager joinTransaction
method. After a persistence context has been joined to a transaction, it remains enlisted until a transaction either
commits or is rolled back. An application can make use of an unsynchronized persistence context's persist, remove,
merge, and refresh entity lifecycle operations without being joined to a JTA transaction. This makes it possible to
perform work against Entities without affecting the underlying data store. If an unsynchronized persistence context
has had lifecycle operations invoked, it can later flush those operations to a database by being joined to a transaction.

Entity Listeners using CDI
It is possible to create a listener for an entity class; which handle lifecycle events. In JPA 2.1, entity listeners became
even more powerful via the support of Contexts and Dependency Injection (CDI). An entity listener can be registered
with an entity class, and that listener can have resources injected into it via CDI. Note that resources are not injected
via the Java EE container, so you can only inject resources available via CDI.
An entity listener class must have a public, no argument constructor. The entity listener class can optionally
define lifecycle callback methods annotated with the PostConstruct and PreDestroy methods. The following
entity listener class, org.javaee7.entity.listener.EmployeeEntityListener , is registered on the
org.javaee7.entity.Employee entity. It demonstrates the new functionality by injecting a mail session into the listener.