Java Reference
In-Depth Information
plication; for example, for EclipseLink you include the -javaagent:path_to/ec-
lipselink.jar argument.
Transaction Handling
JPA can be used within both Java SE and Java EE applications. The platform in use affects
the way JPA transactions are handled.
In Java EE, JPA transactions are part of the application server's Java Transaction API (JTA)
implementation. This offers two choices of how the transaction boundaries are handled: the
application server can take care of the boundaries (using container-managed transactions, or
CMT), or the transaction boundaries can be explicitly programmed in the application (using
user-managed transactions, or UMT).
There is no significant difference in performance between CMT and UMT if they are used
equivalently. However, it is not always possible to use them equivalently. In particular, user-
managed transactions can have a larger or smaller scope than container-managed transac-
tions, which can have a significant impact on performance.
Consider the following pseudocode:
@Stateless
public
public class
Calculator {
@PersistenceContext ( unitName = "Calc" )
EntityManager em ;
class Calculator
@TransactionAttribute ( REQUIRED )
public
public void
void calculate () {
Parameters p = em . find (...);
... perform expensive calculation ...
em . persist (... answer ...);
}
}
The transaction scope here (using CMT) is the entire method. If the method requires repeat-
able read semantics for the data that is being persisted, then data in the table will be locked
during the expensive calculation.
With user-managed transactions, there is more flexibility:
Search WWH ::




Custom Search