Specification: Jakarta Persistence

Version: 3.3-SNAPSHOT

Status: DRAFT

Release: July 02, 2024

Copyright (c) 2019, 2024 Eclipse Foundation.

Eclipse Foundation Specification License - v1.1

By using and/or copying this document, or the Eclipse document from which this statement is linked or incorporated by reference, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions:

Permission to copy, and distribute the contents of this document, or the Eclipse Foundation document from which this statement is linked, in any medium for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the document, or portions thereof, that you use:

  • link or URL to the original Eclipse Foundation document.

  • All existing copyright notices, or if one does not exist, a notice (hypertext is preferred, but a textual representation is permitted) of the form: "Copyright (c) [$date-of-document] Eclipse Foundation AISBL [url to this license] "

Inclusion of the full text of this NOTICE must be provided. We request that authorship attribution be provided in any software, documents, or other items or products that you create pursuant to the implementation of the contents of this document, or any portion thereof.

No right to create modifications or derivatives of Eclipse Foundation documents is granted pursuant to this license, except anyone may prepare and distribute derivative works and portions of this document in software that implements the specification, in supporting materials accompanying such software, and in documentation of such software, PROVIDED that all such works include the notice below. HOWEVER, the publication of derivative works of this document for use as a technical specification is expressly prohibited.

The notice is:

"Copyright (c) [$date-of-document] Eclipse Foundation AISBL. This software or document includes material copied from or derived from [title and URI of the Eclipse Foundation specification document]."

Disclaimers

THIS DOCUMENT IS PROVIDED "AS IS," AND TO THE EXTENT PERMITTED BY APPLICABLE LAW THE COPYRIGHT HOLDERS AND THE ECLIPSE FOUNDATION AISBL MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

TO THE EXTENT PERMITTED BY APPLICABLE LAW THE COPYRIGHT HOLDERS AND THE ECLIPSE FOUNDATION AISBL WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.

The name and trademarks of the copyright holders or the Eclipse Foundation AISBL may NOT be used in advertising or publicity pertaining to this document or its contents without specific, written prior permission. Title to copyright in this document will at all times remain with copyright holders.

1. Introduction

This document is the specification of the Jakarta API for the management of persistence and object/relational mapping in the Jakarta EE and Java SE platforms. The technical objective of this work is to provide a standard object/relational mapping facility for the Java application developer using a Java domain model to manage data held in a relational database.

  • The Jakarta Persistence 3.1 specification is the first release with new features and enhancements after the specification was moved to the Eclipse Foundation.

  • The Jakarta Persistence 3.0 specification was the first release after moving the project to Eclipse Foundation. All APIs were moved from the package javax.* to the package jakarta.*. Every property name containing javax was renamed so that javax is replaced with jakarta.

  • The Java Persistence 2.2 specification enhanced the API with support for repeating annotations; injection into attribute converters; support for mapping the LocalDate, LocalTime, LocalDateTime, OffsetTime, and OffsetDateTime types from java.time; and methods to retrieve the results of Query and TypedQuery as streams.

  • The Java Persistence 2.1 specification added support for schema generation, type conversion methods, use of entity graphs in queries and find operations, unsynchronized persistence contexts, stored procedure invocation, and injection into entity listener classes. It also included enhancements to the query language, the Criteria API, and to the mapping of native queries.

1.1. Authorship

The Jakarta Persistence Specification incorporates work done over two decades by the EJB 3.0 expert group, the Java Persistence 2.0, 2.1, and 2.2 expert groups, under the aegis of the Java Community Process, and by the Jakarta Persistence project at the Eclipse Foundation.

1.2. Document Conventions

Regular serif font is used for information that is prescriptive under this specification.

Italic serif font is used for paragraphs that contain descriptive information, such as notes describing typical use, or notes clarifying the text with prescriptive specification.

Monospaced font is used for code examples and to specify the BNF of the Jakarta Persistence query language.

This document defines the semantics of a set of Java language annotations. An XML descriptor (as specified in Chapter 12) may be used as an alternative to annotations or to augment or override annotations. The elements of this descriptor mirror the annotations and have identical semantics to the corresponding annotations. When semantic requirements are written in terms of annotations, it should be understood that the same semantics apply to the corresponding elements of the XML descriptor.

2. Entities

An entity is a lightweight persistent domain object.[1] Entities support inheritance, polymorphic associations, and polymorphic queries.

The primary programming artifact is the entity class. An entity class may make use of auxiliary classes that serve as helper classes or that are used to represent the state of the entity.

This chapter describes requirements on entity classes and instances.

2.1. The Entity Class

The entity class must be annotated with the Entity annotation or declared as an entity in the XML descriptor.

  • The entity class must be a top-level class or a static inner class. An enum, record, or interface may not be designated as an entity.

  • The entity class must have a public or protected constructor with no parameters, which is called by the persistence provider runtime to instantiate the entity.[2] The entity class may have additional constructors for use by the application.

  • The entity class must be non-final. Every method and persistent instance variable of the entity class must be non-final.

An entity might be an abstract class, or it might be a concrete class. An entity may extend a non-entity class, or it may extend another entity class. A non-entity class may extend an entity class.

The persistent state of an entity is represented by instance variables, which may correspond to JavaBeans properties. An instance variable may be directly accessed only within the methods of the entity, by the entity instance itself. An instance variable of an entity must not be directly accessed by a client of the entity. The state of the entity is available to clients only through the methods of the entity—that is, via accessor (getter/setter) methods, or via other business methods.

2.2. Persistent Fields and Properties

The persistent state of an entity is accessed by the persistence provider runtime via either:

  • property access using JavaBeans-style property accessors, or

  • field access, that is, direct access to instance variables.

The instance variables of a class must have private, protected, or package visibility, independent of whether field access or property access is used. When property access is used, the property accessor methods must be public or protected.

The type of a persistent field or property of an entity class may be:

  • any basic type listed below in Section 2.6, including any Java enum type,

  • an entity type or a collection of some entity type, as specified in Section 2.11,

  • an embeddable class, as defined in Section 2.7, or

  • a collection of a basic type or embeddable type, as specified in Section 2.8.

Object/relational mapping metadata may be specified to customize the object/relational mapping and the loading and storing of the entity state and relationships, as specified in Chapter 11.

The placement of object/relational mapping annotations depends on whether property access or field access is used:

  • When field access is used, mapping annotations must be placed on instance variables, and the persistence provider runtime accesses instance variables directly. Every non-transient instance variable not annotated with the Transient annotation is persistent.

  • When property-based access is used, mapping annotations must be placed on getter methods[3], and the persistence provider runtime accesses persistent state via the property accessor methods. Every property not annotated with the Transient annotation is persistent.

Mapping annotations must not be applied to fields or properties marked transient or Transient, since those fields and properties are not persistent.

Whether property access, field access, or a mix of the two options is used by the provider to access the state of a given entity class or entity hierarchy is determined by the rules defined in Section 2.3.

Terminology Note: The persistent fields and properties of an entity class are generically referred to in this document as “attributes” of the class.

Collection-valued persistent fields and properties must be defined in terms of one of the following collection-valued interfaces, regardless of whether the entity class otherwise adheres to the JavaBeans method conventions noted below, and of whether field or property access is used: java.util.Collection, java.util.Set, java.util.List [4], java.util.Map.

Use of the generic variants of these collection types is strongly encouraged, for example, Set<Order> is preferred to the raw type Set.

Terminology Note: The terms “collection” and “collection-valued” are used in this specification to denote any of the above types, unless further qualified. In cases where a java.util.Collection type (or one of its subtypes) is to be distinguished, the type is identified as such. The terms “map” and “map collection” are used to denote to a collection of type java.util.Map.

A collection implementation type such as HashSet or ArrayList may be used by the application to initialize a collection-valued field or property before the entity is made persistent. Once the entity becomes managed (or detached), subsequent access to the collection must be through the interface type.

2.2.1. Persistent Attribute Type

The enumeration jakarta.persistence.metamodel.Attribute.PersistentAttributeType defines a classification of persistent entity attributes: BASIC for basic attributes, EMBEDDED for embedded attributes, ELEMENT_COLLECTION for element collections, and MANY_TO_ONE, ONE_TO_ONE, ONE_TO_MANY, and MANY_TO_MANY for associations of the indicated multiplicity. Each persistent attribute of an entity belongs to exactly one of the listed types.

It is an error for an attribute of an entity to be annotated with mapping annotations indicating conflicting persistent attribute types. For example, an field may not be annotated @Basic @Embedded, @ManyToOne @ElementCollection, or @OneToOne @ManyToMany. The persistence provider must detect such contradictory combinations of mapping annotations and report the error.[5]

2.2.2. Property Access

When property access is used, persistent properties of the entity class must follow the method signature conventions for JavaBeans read/write properties, as defined by the JavaBeans Introspector class. For every persistent property property of type T of the entity, there must be a getter method, getProperty, and setter method setProperty. For boolean properties, isProperty may be used as an alternative name for the getter method.[6]

For single-valued persistent properties, these method signatures are:

T getProperty()

void setProperty(T t)

For collection-valued persistent properties, the type T in the method signatures above must be one of the collection interface types listed above in Section 2.2.

In addition to returning and setting the persistent state of the entity instance, a property accessor method may contain additional logic, for example, logic to perform validation. The persistence provider runtime triggers execution of this logic when property-based access is used.

Therefore, caution should be exercised in adding business logic to accessor methods when property access is used. The order in which the persistence provider runtime calls these methods when loading or storing persistent state is not defined. Logic contained in such methods should therefore not rely on any specific invocation order.

If property access is used and lazy fetching is specified, portable applications should not directly access the entity state underlying the property methods of managed instances until after it has been fetched by the persistence provider.[7]

If a persistence context is joined to a transaction, runtime exceptions thrown by property accessor methods cause the current transaction to be marked for rollback; any exception thrown by such methods when called by the persistence runtime to load or store persistent state causes the persistence runtime to mark the current transaction for rollback and to throw a PersistenceException wrapping the application exception.

An entity subclass may override a property accessor method inherited from a superclass. However, portable applications must not override the object/relational mapping metadata applied to the persistent fields and properties of entity superclasses.

For example:

@Entity
public class Customer implements Serializable {
    private Long id;
    private String name;
    private Address address;
    private Collection<Order> orders = new HashSet();
    private Set<PhoneNumber> phones = new HashSet();

    // No-arg constructor
    public Customer() {}

    @Id // property access is used
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Address getAddress() {
        return address;
    }

    public void setAddress(Address address) {
        this.address = address;
    }

    @OneToMany
    public Collection<Order> getOrders() {
        return orders;
    }

    public void setOrders(Collection<Order> orders) {
        this.orders = orders;
    }

    @ManyToMany
    public Set<PhoneNumber> getPhones() {
        return phones;
    }

    public void setPhones(Set<PhoneNumber> phones) {
        this.phones = phones;
    }

    // Business method to add a phone number to the customer
    public void addPhone(PhoneNumber phone) {
        this.getPhones().add(phone);

        // Update the phone entity instance to refer to this customer
        phone.addCustomer(this);
    }
}

2.3. Access Type

An access type determines how the persistence provider runtime reads and writes the persistent state of an entity from and to an instance of the entity class, as specified above in Section 2.2. AccessType enumerates the two possibilities:

public enum AccessType {
    FIELD,
    PROPERTY
}

The access type for a persistent attribute depends on the placement of object/relational mapping annotations in the entity class, and may be explicitly overridden via use of the Access annotation defined in Section 11.1.1.

2.3.1. Default Access Type

By default, a single access type (FIELD or PROPERTY) is inferred for an entity hierarchy. The default access type of an entity hierarchy is determined by the placement of mapping annotations on the attributes of the entity classes and mapped superclasses of the entity hierarchy which do not explicitly specify an access type.

  • If mapping annotations are placed on instance variables, FIELD access is inferred.

  • If mapping annotations are placed on getter methods, PROPERTY access is inferred.

An access type may be explicitly specified by means of the Access annotation[8], as described below in Section 2.3.2.

Every class in an entity hierarchy whose access type is defaulted in this way must be consistent in its placement of mapping annotations on either fields or properties, such that a single, consistent default access type applies within the hierarchy. Any embeddable class used by an entity within the hierarchy has the same access type as the default access type of the hierarchy unless the Access annotation is specified, as defined below.

It is an error if a default access type cannot be determined and an access type is not explicitly specified by a class-level Access annotation or the XML descriptor. The behavior of applications which mix the placement of mapping annotations on fields and properties within an entity hierarchy without explicitly specifying the class-level Access annotation is undefined.[9]

2.3.2. Explicit Access Type

The access type of an individual entity class, mapped superclass, or embeddable class may be specified for that class, independent of the default for the entity hierarchy to which it belongs, by annotating the class with the Access annotation.

  • When Access(FIELD) is applied to an entity class, mapped superclass, or embeddable class, mapping annotations may be placed on the instance variables of that class, and the persistence provider runtime accesses persistent state via direct access to the instance variables declared by the class. Every non-transient instance variable not annotated with the Transient annotation is persistent.

  • When Access(PROPERTY) is applied to an entity class, mapped superclass, or embeddable class, mapping annotations may be placed on the properties of that class, and the persistence provider runtime accesses persistent state via the properties declared by that class. Every property not annotated with the Transient annotation is persistent.

The explicit access type may be overridden at the attribute level. That is, a class which explicitly specifies an access type using the Access annotation may also have fields or properties annotated Access, and so the class may have a mix of access types.

  • When Access(FIELD) is specified at the class level, an individual attribute within the class may be selectively designated for property access by annotating a property getter Access(PROPERTY). Mapping annotations for this attribute must be placed on the getter. If a mapping annotation is placed on a property getter which is not annotated Access(PROPERTY), the behavior is undefined.

  • When Access(PROPERTY) is specified at the class level, an individual attribute within the class may be selectively designated for field access by annotating an instance variable Access(FIELD). Mapping annotations for this attribute must be placed on the field. If a mapping annotation is placed on a field which is not annotated Access(FIELD), the behavior is undefined.

It is permitted (but redundant) to place Access(FIELD) on a field whose class has field access or Access(PROPERTY) on a property whose class has property access. On the other hand, the behavior is undefined if:

  • Access(PROPERTY) annotates a field,

  • Access(FIELD) annotates a property getter, or

  • the Access annotation occurs on a property setter.

Portable application should avoid such misplaced @Access annotations.

When access types are combined within a class, the Transient annotation should be used to avoid duplicate persistent mappings. For example:

@Entity @Access(PROPERTY)
public class Customer {
    private Long id;

    @Access(FIELD) // use field access for name
    private String name;

    @Id
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    @Transient // suppress duplicated name attribute
    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    ...
}

The Access annotation does not affect the access type of other entity classes or mapped superclasses in the entity hierarchy. In particular, persistent state inherited from a superclass is always accessed according to the access type of that superclass.

2.3.3. Access Type of an Embeddable Class

The access type of an embeddable class is determined by the access type of the entity class, mapped superclass, or embeddable class in which it is embedded (including as a member of an element collection) independent of whether the access type of the containing class is explicitly specified or defaulted. A different access type for an embeddable class can be specified for that embeddable class by means of the Access annotation as described above in Section 2.3.2.

2.3.4. Defaulted Access Types of Embeddable Classes and Mapped Superclasses

Care must be taken when implementing an embeddable class or mapped superclass which is used both in a context of field access and in a context of property access, and whose access type is not explicitly specified by means of the Access annotation or XML mapping file.

Such a class should be implemented so that the number, names, and types of its persistent attributes are independent of the access type in use. The behavior of an embeddable class or mapped superclass whose attributes are not independent of access type is undefined with regard to use with the metamodel API if the class occurs in contexts of differing access types within the same persistence unit.

2.4. Primary Keys and Entity Identity

Every entity must have a primary key. The value of its primary key uniquely identifies an entity instance within a persistence context and to operations of the EntityManager, as described in Chapter 3.

The primary key must be declared by:

  • the entity class that is the root of the entity hierarchy, or

  • a mapped superclass that is a (direct or indirect) superclass of all entity classes in the entity hierarchy.

A primary key must be defined exactly once in each entity hierarchy.

  • A primary key comprises one or more fields or properties (“attributes”) of the entity class.

  • A simple primary key is a single persistent field or property of the entity class whose type is one of the legal simple primary key types listed below. The Id annotation defined in Section 11.1.22 or id XML element must be used to identify the simple primary key.

  • A composite primary key must correspond to either a single persistent field or property, or to a set of fields or properties, as described below.[10] A primary key class must be defined to represent the composite primary key.

    • If the composite primary key corresponds to a single field or property of the entity, the EmbeddedId annotation defined by Section 11.1.17 identifies the primary key, and the type of the annotated field or property is the primary key class.

    • Otherwise, when the composite primary key corresponds to multiple fields or properties, the Id annotation defined by Section 11.1.22 identifies the fields and properties which comprise the composite key, and the IdClass annotation defined by Section 11.1.23 must specify the primary key class.

A simple primary key or field or property belonging to a composite primary key should have one of the following basic types:

  • any Java primitive type, or java.lang wrapper for a primitive type, [11]

  • java.lang.String,

  • java.util.UUID,

  • java.time.LocalDate, java.util.Date, or java.sql.Date,

  • BigDecimal or BigInteger from java.math.

If a primary key field or property has type java.util.Date, the temporal type must be explicitly specified as DATE using the Temporal annotation defined by Section 11.1.54, or by equivalent XML.

If the primary key is a composite primary key derived from the primary key of another entity, the primary key may contain an attribute whose type is that of the primary key of the referenced entity, as specified below in Section 2.4.2.

An entity with a primary key involving any type other than the types listed above is not portable. If the primary key is generated by the persistence provider, as defined by Section 11.1.21, and its type is not long, int, java.util.UUID, java.lang.String, java.lang.Long, or java.lang.Integer, the entity is not portable.

The application must not change the value of the primary key of an entity instance after the instance is made persistent[12]. If the application does change the value of a primary key of an entity instance after the entity instance is made persistent, the behavior is undefined.[13]

2.4.1. Composite primary keys

The following rules apply to composite primary keys:

  • The primary key class may be a non-abstract regular Java class with a public or protected constructor with no parameters. Alternatively, the primary key class may be any Java record type, in which case it need not have a constructor with no parameters.

  • The access type (FIELD or PROPERTY) of a primary key class is determined by the access type of the entity for which it is the primary key, unless the primary key is an embedded id and an explicit access type is specified using the Access annotation, as defined in Section 2.3.2.

  • If property-based access is used, the properties of the primary key class must be public or protected.

  • The primary key class must define equals and hashCode methods. The semantics of value equality for these methods must be consistent with the database equality for the database types to which the key is mapped.

  • A composite primary key must either be represented and mapped as an embeddable class (see Section 11.1.17) or it must be represented as an id class and mapped to multiple fields or properties of the entity class (see Section 11.1.23).

  • If the composite primary key class is represented as an id class, the names of primary key fields or properties of the primary key class and those of the entity class to which the id class is mapped must correspond and their types must be the same.

  • A primary key which corresponds to a derived identity must conform to the rules specified below in Section 2.4.2.

2.4.2. Primary Keys Corresponding to Derived Identities

The identity of an entity is said to be partially derived from the identity of a second entity when the child or dependent first entity is the owner of a many-to-one or one-to-one relationship which targets the parent second entity and the foreign key referencing the parent entity forms part of the primary key of the dependent entity.

A derived identity might be represented as a simple primary key or as a composite primary key, as described in Section 2.4.2.1 below. The dependent entity class has a composite primary key if

  • it declares one or more primary key attributes in addition to those corresponding to the primary key of the parent, or

  • the parent itself has a composite primary key

and then an embedded id or id class must be used to represent the primary key of the dependent entity. In the case that the parent has a composite key, it is not required that parent entity and dependent entity both use embedded ids, nor that both use id classes.

A ManyToOne or OneToOne relationship which maps a primary key column or columns may be declared using either:

  • the Id annotation, when no other Id or EmbeddedId attribute maps the same primary key column or columns, or

  • the MapsId annotation, if some other attribute or attributes annotated Id or EmbeddedId also map the primary key column or columns.

If a ManyToOne or OneToOne relationship declared by a dependent entity is annotated Id or MapsId, an instance of the entity cannot be made persistent until the relationship has been assigned a reference to an instance of the parent entity, since the identity of the dependent entity declaring the relationship is derived from the referenced parent entity. [14]

A dependent entity may have more than one parent entity.

2.4.2.1. Specification of Derived Identities

If a dependent entity uses an id class to represent its primary key, one of the two following rules must be observed:

  • The names and types of the attributes of the id class and the Id attributes of the dependent entity class must correspond as follows:

    • The Id attribute of the dependent entity class and the corresponding attribute in the id class must have the same name.

    • If an Id attribute of the dependent entity class is of basic type, the corresponding attribute in the id class must have the same type.

    • If an Id attribute of the entity is a ManyToOne or OneToOne relationship to the parent entity, the corresponding attribute in the id class must be of the same Java type as the id class or embedded id of the parent entity (if the parent entity has a composite primary key) or the type of the Id attribute of the parent entity (if the parent entity has a simple primary key).

  • Alternatively, if the dependent entity declares a single primary key attribute, that is, a OneToOne relationship attribute annotated Id, then the id class specified by the dependent entity must be the same as the primary key class of the parent entity.

If a dependent entity uses an embedded id to represent its primary key, the relationship attribute which targets the parent entity must be annotated MapsId.

  • If the embedded id of the dependent entity is of the same Java type as the primary key of the parent entity, then the relationship attribute maps both the relationship to the parent and the primary key of the dependent entity, the relationship attribute must be a OneToOne association, and the MapsId annotation must leave the value element unspecified. [15]

  • Otherwise, the value element of the MapsId annotation must specify the name of the attribute within the embedded id to which the relationship attribute corresponds and this attribute of the embedded id must be of the same type as the primary key of the parent entity.

An attribute of an embedded id which corresponds to a relationship targeting a parent entity is treated by the provider as “read only”—that is, any direct mutation of the attribute is not propagated to the database.

If a dependent entity has a single primary key attribute annotated Id, and the primary key of the parent entity is a simple primary key, then the primary key of the dependent entity is a simple primary key of the same Java type as that of the parent entity, the relationship attribute must be a OneToOne association targeting the parent entity, and either:

  1. the primary key attribute annotated Id is the relationship attribute itself, or

  2. the primary key attribute annotated Id has the same type as the simple primary key of the parent entity, the relationship attribute is annotated MapsId, and the value element of the MapsId annotation is left unspecified.

Neither EmbeddedId nor IdClass is specified for the dependent entity.

2.4.2.2. Mapping of Derived Identities

A dependent entity has derived primary key attributes, and might also have additional primary key attributes which are not derived from any parent entity.

  • Any primary key attribute of a dependent entity which is derived from the identity of a parent entity is mapped by annotations of the corresponding ManyToOne or OneToOne relationship attribute. The default mapping for this relationship is specified in Section 2.12. The default mapping may be overridden by annotating the relationship attribute with the JoinColumn or JoinColumns annotation.

  • If the dependent entity uses an id class, the Column annotation may be used to override the default mapping of Id attributes which are not derived from any parent entity.

  • If the dependent entity uses an embedded id to represent its primary key, the AttributeOverride annotation applied to the EmbeddedId attribute may be used to override the default mapping of embedded id attributes which are not derived from any parent entity.

2.4.2.3. Examples of Derived Identities

The following examples illustrate the rules specified above.

Example 1:

The parent entity has a simple primary key:

@Entity
public class Employee {
    @Id long empId;
    String empName;

    // ...
}

Case (a): The dependent entity uses IdClass to represent a composite key:

public class DependentId {
    String name; // matches name of @Id attribute
    long emp; // matches name of @Id attribute and type of Employee PK
}

@Entity
@IdClass(DependentId.class)
public class Dependent {
    @Id String name;

    // id attribute mapped by join column default
    @Id @ManyToOne
    Employee emp;

    // ...
}

Sample query:

SELECT d
FROM Dependent d
WHERE d.name = 'Joe' AND d.emp.empName = 'Sam'

Case(b): The dependent entity uses EmbeddedId to represent a composite key:

@Embeddable
public class DependentId {
    String name;
    long empPK; // corresponds to PK type of Employee
}

@Entity
public class Dependent {
    @EmbeddedId DependentId id;

    // id attribute mapped by join column default
    @MapsId("empPK") // maps empPK attribute of embedded id
    @ManyToOne
    Employee emp;

    // ...
}

Sample query:

SELECT d
FROM Dependent d
WHERE d.id.name = 'Joe' AND d.emp.empName = 'Sam'

Example 2:

The parent entity uses IdClass:

public class EmployeeId {
    String firstName;
    String lastName;

    // ...
}

@Entity
@IdClass(EmployeeId.class)
public class Employee {
    @Id String firstName
    @Id String lastName

   // ...
}

Case (a): The dependent entity uses IdClass:

public class DependentId {
    String name; // matches name of attribute
    EmployeeId emp; //matches name of attribute and type of Employee PK
}

@Entity
@IdClass(DependentId.class)
public class Dependent {
    @Id
    String name;

    @Id
    @JoinColumns({
        @JoinColumn(name="FK1", referencedColumnName="firstName"),
        @JoinColumn(name="FK2", referencedColumnName="lastName")
    })

    @ManyToOne
    Employee emp;
}

Sample query:

SELECT d
FROM Dependent d
WHERE d.name = 'Joe' AND d.emp.firstName = 'Sam'

Case (b): The dependent entity uses EmbeddedId. The type of the empPK attribute is the same as that of the primary key of Employee. The EmployeeId class needs to be annotated Embeddable or denoted as an embeddable class in the XML descriptor.

@Embeddable
public class DependentId {
    String name;
    EmployeeId empPK;
}

@Entity
public class Dependent {
    @EmbeddedId
    DependentId id;

    @MapsId("empPK")
    @JoinColumns({
        @JoinColumn(name="FK1", referencedColumnName="firstName"),
        @JoinColumn(name="FK2", referencedColumnName="lastName")
    })

    @ManyToOne
    Employee emp;

    // ...
}

Sample query:

SELECT d
FROM Dependent d
WHERE d.id.name = 'Joe' AND d.emp.firstName = 'Sam'

Note that the following alternative query will yield the same result:

SELECT d
FROM Dependent d
WHERE d.id.name = 'Joe' AND d.id.empPK.firstName = 'Sam'

Example 3:

The parent entity uses EmbeddedId:

@Embeddable
public class EmployeeId {
    String firstName;
    String lastName;

    // ...
}

@Entity
public class Employee {
    @EmbeddedId
    EmployeeId empId;

    // ...
}

Case (a): The dependent entity uses IdClass:

public class DependentId {
    String name; // matches name of @Id attribute
    EmployeeId emp; // matches name of @Id attribute and type of embedded id of Employee
}

@Entity
@IdClass(DependentId.class)
public class Dependent {
    @Id
    @Column(name="dep_name") // default column name is overridden
    String name;

    @Id
    @JoinColumns({
        @JoinColumn(name="FK1", referencedColumnName="firstName"),
        @JoinColumn(name="FK2", referencedColumnName="lastName")
    })

    @ManyToOne Employee
    emp;
}

Sample query:

SELECT d
FROM Dependent d
WHERE d.name = 'Joe' and d.emp.empId.firstName = 'Sam'

Case (b): The dependent entity uses EmbeddedId:

@Embeddable
public class DependentId {
    String name;
    EmployeeId empPK; // corresponds to PK type of Employee
}

@Entity
public class Dependent {
    // default column name for "name" attribute is overridden
    @AttributeOverride(name="name", column=@Column(name="dep_name"))
    @EmbeddedId DependentId id;

    @MapsId("empPK")
    @JoinColumns({
        @JoinColumn(name="FK1", referencedColumnName="firstName"),
        @JoinColumn(name="FK2", referencedColumnName="lastName")
    })
    @ManyToOne
    Employee emp;

    // ...
}

Sample query:

SELECT d
FROM Dependent d
WHERE d.id.name = 'Joe' and d.emp.empId.firstName = 'Sam'

Note that the following alternative query will yield the same result:

SELECT d
FROM Dependent d
WHERE d.id.name = 'Joe' AND d.id.empPK.firstName = 'Sam'

Example 4:

The parent entity has a simple primary key:

@Entity
public class Person {
    @Id
    String ssn;

    // ...
}

Case (a): The dependent entity has a single primary key attribute which is mapped by the relationship attribute. The primary key of MedicalHistory is of type String.

@Entity
public class MedicalHistory {
    // default join column name is overridden
    @Id
    @OneToOne
    @JoinColumn(name="FK")
    Person patient;

    // ...
}

Sample query:

SELECT m
FROM MedicalHistory m
WHERE m.patient.ssn = '123-45-6789'

Case (b): The dependent entity has a single primary key attribute corresponding to the relationship attribute. The primary key attribute is of the same basic type as the primary key of the parent entity. The MapsId annotation applied to the relationship attribute indicates that the primary key is mapped by the relationship attribute.[16]

@Entity
public class MedicalHistory {
    @Id
    String id; // overriding not allowed

    // ...

    // default join column name is overridden
    @MapsId
    @JoinColumn(name="FK")
    @OneToOne
    Person patient;

    // ...
}

Sample query:

SELECT m
FROM MedicalHistory m WHERE m.patient.ssn = '123-45-6789'

Example 5:

The parent entity uses IdClass. The dependent’s primary key class is of same type as that of the parent entity.

public class PersonId {
    String firstName;
    String lastName;
}

@Entity
@IdClass(PersonId.class)
public class Person {
    @Id
    String firstName;

    @Id
    String lastName;

    // ...
}

Case (a): The dependent entity uses IdClass:

@Entity
@IdClass(PersonId.class)
public class MedicalHistory {
    @Id
    @JoinColumns({
        @JoinColumn(name="FK1", referencedColumnName="firstName"),
        @JoinColumn(name="FK2", referencedColumnName="lastName")
    })

    @OneToOne
    Person patient;

    // ...
}

Sample query:

SELECT m
FROM MedicalHistory m
WHERE m.patient.firstName = 'Charles'

Case (b): The dependent entity uses the EmbeddedId and MapsId annotations. The PersonId class needs to be annotated Embeddable or denoted as an embeddable class in the XML descriptor.

@Entity
public class MedicalHistory {
    // all attributes map to relationship:
    AttributeOverride not allowed

    @EmbeddedId
    PersonId id;

    // ...

    @MapsId
    @JoinColumns({
        @JoinColumn(name="FK1", referencedColumnName="firstName"),
        @JoinColumn(name="FK2", referencedColumnName="lastName")
    })

    @OneToOne Person patient;

    // ...
}

Sample query:

SELECT m
FROM MedicalHistory m
WHERE m.patient.firstName = 'Charles'

Note that the following alternative query will yield the same result:

SELECT m
FROM MedicalHistory m
WHERE m.id.firstName = 'Charles'

Example 6:

The parent entity uses EmbeddedId. The dependent’s primary key is of the same type as that of the parent.

@Embeddable
public class PersonId {
    String firstName;
    String lastName;
}

@Entity
public class Person {
    @EmbeddedId PersonId id;

    // ...
}

Case (a): The dependent class uses IdClass:

@Entity
@IdClass(PersonId.class)
public class MedicalHistory {
    @Id
    @OneToOne
    @JoinColumns({
        @JoinColumn(name="FK1", referencedColumnName="firstName"),
        @JoinColumn(name="FK2", referencedColumnName="lastName")
    })

    Person patient;

    // ...
}

Case (b): The dependent class uses EmbeddedId:

@Entity
public class MedicalHistory {
    // All attributes are mapped by the relationship
    // AttributeOverride is not allowed
    @EmbeddedId PersonId id;

    // ...

    @MapsId
    @JoinColumns({
        @JoinColumn(name="FK1", referencedColumnName="firstName"),
        @JoinColumn(name="FK2", referencedColumnName="lastName")
    })
    @OneToOne
    Person patient;

    // ...
}

2.5. Entity Versions

An entity might have a version, a persistent field or property used by the persistence provider to perform optimistic locking, as specified in Section 3.5.2. The version field or property holds a version number or timestamp identifying the revision of the entity data held by an entity class instance. In the course of performing lifecycle operations involving the entity instance, the persistence provider gets and sets the version field or property of the entity instance to determine or modify its version number or timestamp. The Version annotation defined in Section 11.1.57 or version XML element must be used to explicitly identify the version field or property of an entity.

An entity class may access the state of its version field or property or export a method which allows other user-written code to access the version, but user-written code must not directly modify the value of the version field or property of an entity instance after the entity is made persistent. [17] With the exception noted in Section 4.11, only the persistence provider is permitted to set or update the entity version. If the application does directly modify the value of the version field or property of an entity instance after it is made persistent, the behavior is undefined.

The version must be of one of the following basic types:

  • int, Integer, short, Short, long, Long, or

  • java.time.LocalDateTime, java.time.Instant, or java.sql.Timestamp.

A portable application must not declare a version field or property with any other type.

An entity class should have at most one version. A portable application must not define an entity class having more than one version field or property.

The version should be declared by the root entity class in an entity class hierarchy, or by one of its mapped superclasses. A portable application must not declare a version field or property in a subclass of the root class of an entity class hierarchy.

2.6. Basic Types

The following Java types are considered basic types:

  • any Java primitive type, or java.lang wrapper class for a primitive type,

  • java.lang.String,

  • java.util.UUID,

  • BigInteger or BigDecimal from java.math,

  • LocalDate, LocalTime, LocalDateTime, OffsetTime, OffsetDateTime, Instant, or Year from java.time,

  • Date or Calendar [18] from java.util [19],

  • Date, Time, or Timestamp from java.sql [20],

  • byte[] or Byte[], char[] or Character[] [21],

  • any Java enum type,

  • any other type which implements java.io.Serializable.

Persistence for basic types is defined in Section 11.1.6 and Section 11.1.18.

2.7. Embeddable Classes

An entity may use other fine-grained classes to represent entity state. Instances of these classes, unlike entity instances, do not have persistent identity of their own. Instead, they exist only as part of the state of the entity to which they belong. An entity may have collections of embeddables as well as single-valued embeddable attributes. Embeddables may also be used as map keys and map values. Embedded objects belong strictly to their owning entity, and are not sharable across persistent entities. Attempting to share an embedded object across entities has undefined semantics.

Embeddable classes must be annotated as Embeddable or denoted in the XML descriptor as such. The access type for an embedded object is determined as described in Section 2.3.

An embeddable class may be a regular Java class which adheres to the requirements specified in Section 2.1 for entities, with the exception that an embeddable class is not annotated as Entity, and an embeddable class may not be abstract.

Alternatively, an embeddable class may be any Java record type.

An embeddable class may be used to represent the state of another embeddable class.

An embeddable class (including an embeddable class within another embeddable class) may contain a collection of a basic type or other embeddable class.[22]

An embeddable class may contain a relationship to an entity or collection of entities. Since instances of embeddable classes themselves have no persistent identity, the relationship from the referenced entity is to the entity that contains the embeddable instance(s) and not to the embeddable itself.[23] An embeddable class that is used as an embedded id or as a map key must not contain such a relationship.

Additional requirements and restrictions on embeddable classes are described in Section 2.8.

2.8. Collections of Embeddable Classes and Basic Types

A persistent field or property of an entity or embeddable class may correspond to a collection of a basic type or embeddable class (“element collection”). Such a collection, when specified as such by the ElementCollection annotation, is mapped by means of a collection table, as defined in Section 11.1.8. If the ElementCollection annotation (or XML equivalent) is not specified for the collection-valued field or property, the rules of Section 2.10 apply.

An embeddable class (including an embeddable class within another embeddable class) that is contained within an element collection must not contain an element collection, nor may it contain a relationship to an entity other than a many-to-one or one-to-one relationship. The embeddable class must be on the owning side of such a relationship and the relationship must be mapped by a foreign key mapping. (See Section 2.11)

2.9. Map Collections

Collections of elements and entity relationships can be represented as java.util.Map collections.

The map key and the map value independently can each be a basic type, an embeddable class, or an entity.

The ElementCollection, OneToMany, and ManyToMany annotations are used to specify the map as an element collection or entity relationship as follows: when the map value is a basic type or embeddable class, the ElementCollection annotation is used; when the map value is an entity, the OneToMany or ManyToMany annotation is used.

Bidirectional relationships represented as java.util.Map collections support the use of the Map datatype on one side of the relationship only.

2.9.1. Map Keys

If the map key type is a basic type, the MapKeyColumn annotation can be used to specify the column mapping for the map key. If the MapKeyColumn annotation is not specified, the default values of the MapKeyColumn annotation apply as described in Section 11.1.34.

If the map key type is an embeddable class, the mappings for the map key columns are defaulted according to the default column mappings for the embeddable class. (See Section 11.1.9). The AttributeOverride and AttributeOverrides annotations can be used to override these mappings, as described in Section 11.1.4 and Section 11.1.5. If an embeddable class is used as a map key, the embeddable class must implement the hashCode and equals methods consistently with the database columns to which the embeddable is mapped[24].

If the map key type is an entity, the MapKeyJoinColumn and MapKeyJoinColumns annotations are used to specify the column mappings for the map key. If the primary key of the referenced entity is a simple primary key and the MapKeyJoinColumn annotation is not specified, the default values of the MapKeyJoinColumn annotation apply as described in Section 11.1.36.

If Java generic types are not used in the declaration of a relationship attribute of type java.util.Map, the MapKeyClass annotation must be used to specify the type of the key of the map.

The MapKey annotation is used to specify the special case where the map key is itself the primary key or a persistent field or property of the entity that is the value of the map. The MapKeyClass annotation is not used when MapKey is specified.

2.9.2. Map Values

When the value type of the map is a basic type or an embeddable class, a collection table is used to map the map. If Java generic types are not used, the targetClass element of the ElementCollection annotation must be used to specify the value type for the map. The default column mappings for the map value are derived according to the default mapping rules for the CollectionTable annotation defined in Section 11.1.8. The Column annotation is used to override these defaults for a map value of basic type. The AttributeOverride(s) and AssociationOverride(s) annotations are used to override the mappings for a map value that is an embeddable class.

When the value type of the map is an entity, a join table is used to map the map for a many-to-many relationship or, by default, for a one-to-many unidirectional relationship. If the relationship is a bidirectional one-to-many/many-to-one relationship, by default the map is mapped in the table of the entity that is the value of the map. If Java generic types are not used, the targetEntity element of the OneToMany or ManyToMany annotation must be used to specify the value type for the map. Default mappings are described in Section 2.12.

2.10. Mapping Defaults for Non-Relationship Fields or Properties

If a persistent field or property other than a relationship property is not annotated with one of the mapping annotations defined in Chapter 11 (and no equivalent mapping information is specified in any XML descriptor), the following default mapping rules are applied in order:

It is an error if no annotation is present and neither of the above rules apply.

2.11. Entity Relationships

Relationships among entities may be one-to-one, one-to-many, many-to-one, or many-to-many. Relationships are polymorphic.

If there is an association between two entities, one of the following relationship modeling annotations must be applied to the corresponding persistent property or field of the referencing entity: OneToOne, OneToMany, ManyToOne, ManyToMany. For associations that do not specify the target type (e.g., where Java generic types are not used for collections), it is necessary to specify the entity that is the target of the relationship.[25] Equivalent XML elements may be used as an alternative to these mapping annotations.

These annotations mirror common practice in relational database schema modeling. The use of the relationship modeling annotations allows the object/relationship mapping of associations to the relational database schema to be fully defaulted, to provide an ease-of-development facility. This is described in Section 2.12.

Relationships may be bidirectional or unidirectional. A bidirectional relationship has both an owning side and an inverse (non-owning) side. A unidirectional relationship has only an owning side. The owning side of a relationship determines the updates to the relationship in the database, as described in Section 3.3.4.

The following rules apply to bidirectional relationships:

The inverse side of a bidirectional relationship must refer to its owning side by use of the mappedBy element of the OneToOne, OneToMany, or ManyToMany annotation. The mappedBy element designates the property or field in the entity that is the owner of the relationship.

  • The many side of one-to-many / many-to-one bidirectional relationships must be the owning side, hence the mappedBy element cannot be specified on the ManyToOne annotation.

  • For one-to-one bidirectional relationships, the owning side corresponds to the side that contains the corresponding foreign key.

  • For many-to-many bidirectional relationships either side may be the owning side.

The relationship modeling annotation constrains the use of the cascade=REMOVE specification. The cascade=REMOVE specification should only be applied to associations that are specified as OneToOne or OneToMany. Applications that apply cascade=REMOVE to other associations are not portable.

Associations that are specified as OneToOne or OneToMany support use of the orphanRemoval option. The following behaviors apply when orphanRemoval is in effect:

  • If an entity that is the target of the relationship is removed from the relationship (by setting the relationship to null or removing the entity from the relationship collection), the remove operation will be applied to the entity being orphaned. The remove operation is applied at the time of the flush operation. The orphanRemoval functionality is intended for entities that are privately “owned” by their parent entity. Portable applications must otherwise not depend upon a specific order of removal, and must not reassign an entity that has been orphaned to another relationship or otherwise attempt to persist it. If the entity being orphaned is a detached, new, or removed entity, the semantics of orphanRemoval do not apply.

  • If the remove operation is applied to a managed source entity, the remove operation will be cascaded to the relationship target in accordance with the rules of Section 3.3.3, (and hence it is not necessary to specify cascade=REMOVE for the relationship)[26].

Section 2.12, defines relationship mapping defaults for entity relationships. Additional mapping annotations (e.g., column and table mapping annotations) may be specified to override or further refine the default mappings and mapping strategies described in Section 2.12.

In addition, this specification also requires support for the following alternative mapping strategies:

  • The mapping of unidirectional one-to-many relationships by means of foreign key mappings. The JoinColumn annotation or corresponding XML element must be used to specify such non-default mappings. See Section 11.1.26.

  • The mapping of unidirectional and bidirectional one-to-one relationships, bidirectional many-to-one/one-to-many relationships, and unidirectional many-to-one relationships by means of join table mappings. The JoinTable annotation or corresponding XML element must be used to specify such non-default mappings. See Section 11.1.28.

Such mapping annotations must be specified on the owning side of the relationship. Any overriding of mapping defaults must be consistent with the relationship modeling annotation that is specified. For example, if a many-to-one relationship mapping is specified, it is not permitted to specify a unique key constraint on the foreign key for the relationship.

The persistence provider handles the object/relational mapping of the relationships, including their loading and storing to the database as specified in the metadata of the entity class, and the referential integrity of the relationships as specified in the database (e.g., by foreign key constraints).

Note that it is the application that bears responsibility for maintaining the consistency of runtime relationships—for example, for insuring that the “one” and the “many” sides of a bidirectional relationship are consistent with one another when the application updates the relationship at runtime.

If there are no associated entities for a multi-valued relationship of an entity fetched from the database, the persistence provider is responsible for returning an empty collection as the value of the relationship.

2.12. Relationship Mapping Defaults

This section defines the mapping defaults that apply to the use of the OneToOne, OneToMany, ManyToOne, and ManyToMany relationship modeling annotations. The same mapping defaults apply when the XML descriptor is used to denote the relationship cardinalities.

2.12.1. Bidirectional OneToOne Relationships

Assuming that:

  • Entity A references a single instance of Entity B.

  • Entity B references a single instance of Entity A.

  • Entity A is specified as the owner of the relationship.

The following mapping defaults apply:

  • Entity A is mapped to a table named A.

  • Entity B is mapped to a table named B.

  • Table A contains a foreign key to table B. The foreign key column name is formed as the concatenation of the following: the name of the relationship property or field of entity A; " _ "; the name of the primary key column in table B. The foreign key column has the same type as the primary key of table B and there is a unique key constraint on it.

Example:

@Entity
public class Employee {
    private Cubicle assignedCubicle;

    @OneToOne
    public Cubicle getAssignedCubicle() {
        return assignedCubicle;
    }

    public void setAssignedCubicle(Cubicle cubicle) {
        this.assignedCubicle = cubicle;
    }

    // ...
}

@Entity
public class Cubicle {
    private Employee residentEmployee;

    @OneToOne(mappedBy="assignedCubicle")
    public Employee getResidentEmployee() {
        return residentEmployee;
    }

    public void setResidentEmployee(Employee employee) {
        this.residentEmployee = employee;
    }

    // ...
}

In this example:

  • Entity Employee references a single instance of Entity Cubicle.

  • Entity Cubicle references a single instance of Entity Employee.

  • Entity Employee is the owner of the relationship.

The following mapping defaults apply:

  • Entity Employee is mapped to a table named EMPLOYEE.

  • Entity Cubicle is mapped to a table named CUBICLE.

  • Table EMPLOYEE contains a foreign key to table CUBICLE. The foreign key column is named ASSIGNEDCUBICLE_<PK of CUBICLE>, where <PK of CUBICLE> denotes the name of the primary key column of table CUBICLE. The foreign key column has the same type as the primary key of CUBICLE, and there is a unique key constraint on it.

2.12.2. Bidirectional ManyToOne / OneToMany Relationships

Assuming that:

  • Entity A references a single instance of Entity B.

  • Entity B references a collection of Entity A[27].

  • Entity A must be the owner of the relationship.

The following mapping defaults apply:

  • Entity A is mapped to a table named A.

  • Entity B is mapped to a table named B.

  • Table A contains a foreign key to table B. The foreign key column name is formed as the concatenation of the following: the name of the relationship property or field of entity A; " _ "; the name of the primary key column in table B. The foreign key column has the same type as the primary key of table B.

Example:

@Entity
public class Employee {
    private Department department;

    @ManyToOne
    public Department getDepartment() {
        return department;
    }

    public void setDepartment(Department department) {
        this.department = department;
    }

    // ...
}

@Entity
public class Department {
    private Collection<Employee> employees = new HashSet();

    @OneToMany(mappedBy="department")
    public Collection<Employee> getEmployees() {
        return employees;
    }

    public void setEmployees(Collection<Employee> employees) {
        this.employees = employees;
    }

    // ...
}

In this example:

  • Entity Employee references a single instance of Entity Department.

  • Entity Department references a collection of Entity Employee.

  • Entity Employee is the owner of the relationship.

The following mapping defaults apply:

  • Entity Employee is mapped to a table named EMPLOYEE.

  • Entity Department is mapped to a table named DEPARTMENT.

  • Table EMPLOYEE contains a foreign key to table DEPARTMENT. The foreign key column is named DEPARTMENT_<PK of DEPARTMENT>, where <PK of DEPARTMENT> denotes the name of the primary key column of table DEPARTMENT. The foreign key column has the same type as the primary key of DEPARTMENT.

2.12.3. Unidirectional Single-Valued Relationships

Assuming that:

  • Entity A references a single instance of Entity B.

  • Entity B does not reference Entity A.

A unidirectional relationship has only an owning side, which in this case must be Entity A.

The unidirectional single-valued relationship modeling case can be specified as either a unidirectional OneToOne or as a unidirectional ManyToOne relationship.

2.12.3.1. Unidirectional OneToOne Relationships

The following mapping defaults apply:

  • Entity A is mapped to a table named A.

  • Entity B is mapped to a table named B.

  • Table A contains a foreign key to table B. The foreign key column name is formed as the concatenation of the following: the name of the relationship property or field of entity A; " _ "; the name of the primary key column in table B. The foreign key column has the same type as the primary key of table B and there is a unique key constraint on it.

Example:

@Entity
public class Employee {
    private TravelProfile profile;

    @OneToOne
    public TravelProfile getProfile() {
        return profile;
    }

    public void setProfile(TravelProfile profile) {
        this.profile = profile;
    }

    // ...
}

@Entity
public class TravelProfile {
    // ...
}

In this example:

  • Entity Employee references a single instance of Entity TravelProfile.

  • Entity TravelProfile does not reference Entity Employee.

  • Entity Employee is the owner of the relationship.

The following mapping defaults apply:

  • Entity Employee is mapped to a table named EMPLOYEE.

  • Entity TravelProfile is mapped to a table named TRAVELPROFILE.

  • Table EMPLOYEE contains a foreign key to table TRAVELPROFILE. The foreign key column is named PROFILE_<PK of TRAVELPROFILE>, where <PK of TRAVELPROFILE> denotes the name of the primary key column of table TRAVELPROFILE. The foreign key column has the same type as the primary key of TRAVELPROFILE, and there is a unique key constraint on it.

2.12.3.2. Unidirectional ManyToOne Relationships

The following mapping defaults apply:

  • Entity A is mapped to a table named A.

  • Entity B is mapped to a table named B.

  • Table A contains a foreign key to table B. The foreign key column name is formed as the concatenation of the following: the name of the relationship property or field of entity A; "_"; the name of the primary key column in table B. The foreign key column has the same type as the primary key of table B.

Example:

@Entity
public class Employee {
    private Address address;

    @ManyToOne
    public Address getAddress() {
        return address;
    }

    public void setAddress(Address address) {
        this.address = address;
    }

    // ...
}

@Entity
public class Address {
    // ...
}

In this example:

  • Entity Employee references a single instance of Entity Address.

  • Entity Address does not reference Entity Employee.

  • Entity Employee is the owner of the relationship.

The following mapping defaults apply:

  • Entity Employee is mapped to a table named EMPLOYEE.

  • Entity Address is mapped to a table named ADDRESS.

  • Table EMPLOYEE contains a foreign key to table ADDRESS. The foreign key column is named ADDRESS_<PK of ADDRESS>, where <PK of ADDRESS> denotes the name of the primary key column of table ADDRESS. The foreign key column has the same type as the primary key of ADDRESS.

2.12.4. Bidirectional ManyToMany Relationships

Assuming that:

  • Entity A references a collection of Entity B.

  • Entity B references a collection of Entity A.

  • Entity A is the owner of the relationship.

The following mapping defaults apply:

  • Entity A is mapped to a table named A.

  • Entity B is mapped to a table named B.

  • There is a join table that is named A_B (owner name first). This join table has two foreign key columns. One foreign key column refers to table A and has the same type as the primary key of table A. The name of this foreign key column is formed as the concatenation of the following: the name of the relationship property or field of entity B; " _ "; the name of the primary key column in table A. The other foreign key column refers to table B and has the same type as the primary key of table B. The name of this foreign key column is formed as the concatenation of the following: the name of the relationship property or field of entity A; " _ "; the name of the primary key column in table B.

Example:

@Entity
public class Project {
    private Collection<Employee> employees;

    @ManyToMany
    public Collection<Employee> getEmployees() {
        return employees;
    }

    public void setEmployees(Collection<Employee> employees) {
        this.employees = employees;
    }

    // ...
}

@Entity
public class Employee {
    private Collection<Project> projects;

    @ManyToMany(mappedBy="employees")
    public Collection<Project> getProjects() {
        return projects;
    }

    public void setProjects(Collection<Project> projects) {
        this.projects = projects;
    }

    // ...
}

In this example:

  • Entity Project references a collection of Entity Employee.

  • Entity Employee references a collection of Entity Project.

  • Entity Project is the owner of the relationship.

The following mapping defaults apply:

  • Entity Project is mapped to a table named PROJECT.

  • Entity Employee is mapped to a table named EMPLOYEE.

  • There is a join table that is named PROJECT_EMPLOYEE (owner name first). This join table has two foreign key columns. One foreign key column refers to table PROJECT and has the same type as the primary key of PROJECT. The name of this foreign key column is PROJECTS_<PK of PROJECT>, where <PK of PROJECT> denotes the name of the primary key column of table PROJECT. The other foreign key column refers to table EMPLOYEE and has the same type as the primary key of EMPLOYEE. The name of this foreign key column is EMPLOYEES_<PK of EMPLOYEE>, where <PK of EMPLOYEE> denotes the name of the primary key column of table EMPLOYEE.

2.12.5. Unidirectional Multi-Valued Relationships

Assuming that:

  • Entity A references a collection of Entity B.

  • Entity B does not reference Entity A.

A unidirectional relationship has only an owning side, which in this case must be Entity A.

The unidirectional multi-valued relationship modeling case can be specified as either a unidirectional OneToMany or as a unidirectional ManyToMany relationship.

2.12.5.1. Unidirectional OneToMany Relationships

The following mapping defaults apply:

  • Entity A is mapped to a table named A.

  • Entity B is mapped to a table named B.

  • There is a join table that is named A_B (owner name first). This join table has two foreign key columns. One foreign key column refers to table A and has the same type as the primary key of table A. The name of this foreign key column is formed as the concatenation of the following: the name of entity A; " _ "; the name of the primary key column in table A. The other foreign key column refers to table B and has the same type as the primary key of table B and there is a unique key constraint on it. The name of this foreign key column is formed as the concatenation of the following: the name of the relationship property or field of entity A; " _ "; the name of the primary key column in table B.

Example:

@Entity
public class Employee {
    private Collection<AnnualReview> annualReviews;

    @OneToMany
    public Collection<AnnualReview> getAnnualReviews() {
        return annualReviews;
    }

    public void setAnnualReviews(Collection<AnnualReview> annualReviews) {
        this.annualReviews = annualReviews;
    }

    // ...
}

@Entity
public class AnnualReview {
    // ...
}

In this example:

  • Entity Employee references a collection of Entity AnnualReview.

  • Entity AnnualReview does not reference Entity Employee.

  • Entity Employee is the owner of the relationship.

The following mapping defaults apply:

  • Entity Employee is mapped to a table named EMPLOYEE.

  • Entity AnnualReview is mapped to a table named ANNUALREVIEW.

  • There is a join table that is named EMPLOYEE_ANNUALREVIEW (owner name first). This join table has two foreign key columns. One foreign key column refers to table EMPLOYEE and has the same type as the primary key of EMPLOYEE. This foreign key column is named EMPLOYEE_<PK of EMPLOYEE>, where <PK of EMPLOYEE> denotes the name of the primary key column of table EMPLOYEE. The other foreign key column refers to table ANNUALREVIEW and has the same type as the primary key of ANNUALREVIEW. This foreign key column is named ANNUALREVIEWS_<PK of ANNUALREVIEW>, where <PK of ANNUALREVIEW> denotes the name of the primary key column of table ANNUALREVIEW. There is a unique key constraint on the foreign key that refers to table ANNUALREVIEW.

2.12.5.2. Unidirectional ManyToMany Relationships

The following mapping defaults apply:

  • Entity A is mapped to a table named A.

  • Entity B is mapped to a table named B.

  • There is a join table that is named A_B (owner name first). This join table has two foreign key columns. One foreign key column refers to table A and has the same type as the primary key of table A. The name of this foreign key column is formed as the concatenation of the following: the name of entity A; " _ "; the name of the primary key column in table A. The other foreign key column refers to table B and has the same type as the primary key of table B. The name of this foreign key column is formed as the concatenation of the following: the name of the relationship property or field of entity A; " _ "; the name of the primary key column in table B.

Example:

@Entity
public class Employee {
    private Collection<Patent> patents;

    @ManyToMany
    public Collection<Patent> getPatents() {
        return patents;
    }

    public void setPatents(Collection<Patent> patents) {
        this.patents = patents;
    }

    // ...
}

@Entity
public class Patent {
    //...
}

In this example:

  • Entity Employee references a collection of Entity Patent.

  • Entity Patent does not reference Entity Employee.

  • Entity Employee is the owner of the relationship.

The following mapping defaults apply:

  • Entity Employee is mapped to a table named EMPLOYEE.

  • Entity Patent is mapped to a table named PATENT.

  • There is a join table that is named EMPLOYEE_PATENT (owner name first). This join table has two foreign key columns. One foreign key column refers to table EMPLOYEE and has the same type as the primary key of EMPLOYEE. This foreign key column is named EMPLOYEE_<PK of EMPLOYEE>, where <PK of EMPLOYEE> denotes the name of the primary key column of table EMPLOYEE. The other foreign key column refers to table PATENT and has the same type as the primary key of PATENT. This foreign key column is named PATENTS_<PK of PATENT>, where <PK of PATENT> denotes the name of the primary key column of table PATENT.

2.13. Inheritance

An entity may inherit from another entity class. Entities support inheritance, polymorphic associations, and polymorphic queries.

Both abstract and concrete classes can be entities. Both abstract and concrete classes can be annotated with the Entity annotation, mapped as entities, and queried for as entities.

Entities can extend non-entity classes and non-entity classes can extend entity classes.

These concepts are described further in the following sections.

2.13.1. Abstract Entity Classes

An abstract class can be specified as an entity. An abstract entity differs from a concrete entity only in that it cannot be directly instantiated. An abstract entity is mapped as an entity and can be the target of queries (which will operate over and/or retrieve instances of its concrete subclasses).

An abstract entity class is annotated with the Entity annotation or denoted in the XML descriptor as an entity.

The following example shows the use of an abstract entity class in the entity inheritance hierarchy.

Example: Abstract class as an Entity

@Entity
@Table(name="EMP")
@Inheritance(strategy=JOINED)
public abstract class Employee {
    @Id
    protected Integer empId;

    @Version
    protected Integer version;

    @ManyToOne
    protected Address address;

    // ...
}

@Entity
@Table(name="FT_EMP")
@DiscriminatorValue("FT")
@PrimaryKeyJoinColumn(name="FT_EMPID")
public class FullTimeEmployee extends Employee {
    // Inherit empId, but mapped in this class to FT_EMP.FT_EMPID
    // Inherit version mapped to EMP.VERSION
    // Inherit address mapped to EMP.ADDRESS fk

    // Defaults to FT_EMP.SALARY
    protected Integer salary;

    // ...
}

@Entity
@Table(name="PT_EMP")
@DiscriminatorValue("PT")
// PK column is PT_EMP.EMPID due to `PrimaryKeyJoinColumn` default
public class PartTimeEmployee extends Employee {
    protected Float hourlyWage;

    // ...
}

2.13.2. Mapped Superclasses

An entity may inherit from a superclass that provides persistent entity state and mapping information, but which is not itself an entity. Typically, the purpose of such a mapped superclass is to define state and mapping information that is common to multiple entity classes.

A mapped superclass, unlike an entity, is not queryable and must not be passed as an argument to EntityManager or Query operations. Persistent relationships defined by a mapped superclass must be unidirectional.

Both abstract and concrete classes may be specified as mapped superclasses. The MappedSuperclass annotation (or mapped-superclass XML descriptor element) is used to designate a mapped superclass.

A class designated as a mapped superclass has no separate table defined for it. Its mapping information is applied to the entities that inherit from it.

The persistent attributes of a mapped superclass may be mapped in the same way as the attributes of an entity class. Such mappings apply only to the entity subclasses of the mapped superclass, since no table exists for the mapped superclass itself. When applied to a subclass, the inherited mappings are interpreted in the context of the tables mapped by subclass. Mapping information inherited from a mapped superclass can be overridden in such subclasses using the AttributeOverride and AssociationOverride annotations or corresponding XML elements.

All other entity mapping defaults apply equally to a class designated as a mapped superclass.

The following example illustrates the definition of a concrete class as a mapped superclass.

Example: Concrete class as a mapped superclass

@MappedSuperclass
public class Employee {
    @Id
    protected Integer empId;

    @Version
    protected Integer version;

    @ManyToOne
    @JoinColumn(name="ADDR")
    protected Address address;

    public Integer getEmpId() { ... }

    public void setEmpId(Integer id) { ... }

    public Address getAddress() { ... }

    public void setAddress(Address addr) { ... }
}

// Default table is FTEMPLOYEE table
@Entity
public class FTEmployee extends Employee {
    // Inherited empId field mapped to FTEMPLOYEE.EMPID
    // Inherited version field mapped to FTEMPLOYEE.VERSION
    // Inherited address field mapped to FTEMPLOYEE.ADDR fk

    // Defaults to FTEMPLOYEE.SALARY
    protected Integer salary;

    public FTEmployee() {}

    public Integer getSalary() { ... }

    public void setSalary(Integer salary) { ... }
}

@Entity
@Table(name="PT_EMP")
@AssociationOverride(name="address", joincolumns=@JoinColumn(name="ADDR_ID"))
public class PartTimeEmployee extends Employee {
    // Inherited empId field mapped to PT_EMP.EMPID
    // Inherited version field mapped to PT_EMP.VERSION
    // address field mapping overridden to PT_EMP.ADDR_ID fk
    @Column(name="WAGE")
    protected Float hourlyWage;

    public PartTimeEmployee() {}

    public Float getHourlyWage() { ... }

    public void setHourlyWage(Float wage) { ... }
}

2.13.3. Non-Entity Classes in the Entity Inheritance Hierarchy

An entity can have a non-entity superclass, which may be either a concrete or abstract class.[28]

The non-entity superclass serves for inheritance of behavior only. The state of a non-entity superclass is not persistent. Any state inherited from non-entity superclasses is non-persistent in an inheriting entity class. This non-persistent state is not managed by the entity manager[29]. Any annotations on such superclasses are ignored.

Non-entity classes cannot be passed as arguments to methods of the EntityManager or Query interfaces[30] and cannot bear mapping information.

The following example illustrates the use of a non-entity class as a superclass of an entity.

Example: Non-entity superclass

public class Cart {
    protected Integer operationCount; // transient state

    public Cart() {
        operationCount = 0;
    }

    public Integer getOperationCount() {
        return operationCount;
    }

    public void incrementOperationCount() {
        operationCount++;
    }
}

@Entity
public class ShoppingCart extends Cart {
    Collection<Item> items = new Vector<Item>();

    public ShoppingCart() {
        super();
    }

    // ...

    @OneToMany
    public Collection<Item> getItems() {
        return items;
    }

    public void addItem(Item item) {
        items.add(item);
        incrementOperationCount();
    }
}

2.14. Inheritance Mapping Strategies

The mapping of class hierarchies is specified through metadata.

There are three basic strategies that are used when mapping a class or class hierarchy to a relational database:

  • a single table per class hierarchy

  • a joined subclass strategy, in which fields that are specific to a subclass are mapped to a separate table than the fields that are common to the parent class, and a join is performed to instantiate the subclass.

  • a table per concrete entity class

An implementation is required to support the single table per class hierarchy inheritance mapping strategy and the joined subclass strategy.

Support for the table per concrete class inheritance mapping strategy is optional in this release. Applications that use this mapping strategy will not be portable.

Support for the combination of inheritance strategies within a single entity inheritance hierarchy is not required by this specification.

2.14.1. Single Table per Class Hierarchy Strategy

In this strategy, all the classes in a hierarchy are mapped to a single table. The table has a column that serves as a “discriminator column”, that is, a column whose value identifies the specific subclass to which the instance that is represented by the row belongs.

This mapping strategy provides good support for polymorphic relationships between entities and for queries that range over the class hierarchy.

It has the drawback, however, that it requires that the columns that correspond to state specific to the subclasses be nullable.

2.14.2. Joined Subclass Strategy

In the joined subclass strategy, the root of the class hierarchy is represented by a single table. Each subclass is represented by a separate table that contains those fields that are specific to the subclass (not inherited from its superclass), as well as the column(s) that represent its primary key. The primary key column(s) of the subclass table serves as a foreign key to the primary key of the superclass table.

This strategy provides support for polymorphic relationships between entities.

It has the drawback that it requires that one or more join operations be performed to instantiate instances of a subclass. In deep class hierarchies, this may lead to unacceptable performance. Queries that range over the class hierarchy likewise require joins.

2.14.3. Table per Concrete Class Strategy

In this mapping strategy, each class is mapped to a separate table. All properties of the class, including inherited properties, are mapped to columns of the table for the class.

This strategy has the following drawbacks:

  • It provides poor support for polymorphic relationships.

  • It typically requires that SQL UNION queries (or a separate SQL query per subclass) be issued for queries that are intended to range over the class hierarchy.

2.15. Naming of Database Objects

Many annotations and annotation elements contain names of database objects or assume default names for database objects.

This specification requires the following with regard to the interpretation of the names referencing database objects. These names include the names of tables, columns, and other database elements. Such names also include names that result from defaulting (e.g., a table name that is defaulted from an entity name or a column name that is defaulted from a field or property name).

By default, the names of database objects must be treated as undelimited identifiers and passed to the database as such.

For example, assuming the use of an English locale, the following must be passed to the database as undelimited identifers so that they will be treated as equivalent for all databases that comply with the SQL Standard’s requirements for the treatment of “regular identifiers” (undelimited identifiers) and “delimited identifiers” [2]:

@Table(name="Customer")
@Table(name="customer")
@Table(name="cUsTomer")

Similarly, the following must be treated as equivalent:

@JoinColumn(name="CUSTOMER")
@ManyToOne Customer customer;

@JoinColumn(name="customer")
@ManyToOne Customer customer;

@ManyToOne Customer customer;

To specify delimited identifiers, one of the following approaches must be used:

  • It is possible to specify that all database identifiers in use for a persistence unit be treated as delimited identifiers by specifying the <delimited-identifiers/> element within the persistence-unit-defaults element of the object/relational xml mapping file. If the <delimited-identifiers/> element is specified, it cannot be overridden.

  • It is possible to specify on a per-name basis that a name for a database object is to be interpreted as a delimited identifier as follows:

    • Using annotations, a name is specified as a delimited identifier by enclosing the name within double quotes, whereby the inner quotes are escaped, e.g., @Table(name="\"customer\"").

    • When using XML, a name is specified as a delimited identifier by use of double quotes, e.g., <table name="&quot;customer&quot;"/> [31]

The following annotations contain elements whose values correspond to names of database identifiers and for which the above rules apply, including when their use is nested within that of other annotations:

  • EntityResult(discriminatorColumn element)

  • FieldResult(column element)

  • ColumnResult(name element)

  • CollectionTable(name, catalog, schema elements)

  • Column(name, columnDefinition, table elements)

  • DiscriminatorColumn(name, columnDefinition elements)

  • ForeignKey(name, foreignKeyDefinition elements)

  • Index(name, columnList elements)

  • JoinColumn(name, referencedColumnName, columnDefinition, table elements)

  • JoinTable(name, catalog, schema elements)

  • MapKeyColumn(name, columnDefinition, table elements)

  • MapKeyJoinColumn(name, referencedColumnName, columnDefinition, table elements)

  • NamedStoredProcedureQuery(procedureName element)

  • OrderColumn(name, columnDefinition elements)

  • PrimaryKeyJoinColumn(name, referencedColumnName, columnDefinition elements)

  • SecondaryTable(name, catalog, schema elements)

  • SequenceGenerator(sequenceName, catalog, schema elements)

  • StoredProcedureParameter(name element)

  • Table(name, catalog, schema elements)

  • TableGenerator(table, catalog, schema, pkColumnName, valueColumnName elements)

  • UniqueConstraint(name, columnNames elements)

The following XML elements and types contain elements or attributes whose values correspond to names of database identifiers and for which the above rules apply:

  • entity-mappings(schema, catalog elements)

  • persistence-unit-defaults(schema, catalog elements)

  • collection-table(name, catalog, schema attributes)

  • column(name, table, column-definition attributes)

  • column-result(name attribute)

  • discriminator-column(name, column-definition attributes)

  • entity-result(discriminator-column attribute)

  • field-result(column attribute)

  • foreign-key(name, foreign-key-definition attributes)

  • index(name attribute, column-list element)

  • join-column(name, referenced-column-name, column-definition, table attributes)

  • join-table(name, catalog, schema attributes)

  • map-key-column(name, column-definition, table attributes)

  • map-key-join-column(name, referenced-column-name, column-definition, table attributes)

  • named-stored-procedure-query(procedure-name attribute)

  • order-column(name, column-definition attributes)

  • primary-key-join-column(name, referenced-column-name, column-definition attributes)

  • secondary-table(name, catalog, schema attributes)

  • sequence-generator(sequence-name, catalog, schema attributes)

  • stored-procedure-parameter(name attribute)

  • table(name, catalog, schema attributes)

  • table-generator(table, catalog, schema, pk-column-name, value-column-name attributes)

  • unique-constraint(name attribute, column-name element)

3. Entity Operations

This chapter describes:

  • the use of the EntityManager and Query APIs to retrieve instances of entity classes representing persistent state held in the database, and of EntityGraph to control the limits of the object graph returned by such operations,

  • the use of the EntityManager API to manage the lifecycle of entity instances associated with a persistence context, and to control the synchronization of state held in the persistence context with the database,

  • the use of the second-level cache, and

  • entity listeners and lifeycle callbacks, attribute converters, and integration with Bean Validation.

3.1. Overview

Every instance of EntityManager has an associated persistence context. A persistence context is a set of entity instances in which for any given persistent entity identity there is a unique entity instance. Within the persistence context, the entity instances and their lifecycle are managed. The entity instance lifecycle is defined in Section 3.3. The relationship between entity managers and persistence contexts is described in Section 3.4, and again in further detail in Chapter 7.

The EntityManager interface defines the methods used to interact with its persistence context. The EntityManager API is used to create and remove persistent entity instances, to find persistent entities by primary key, and to query over persistent entity types. Section 3.2 describes the EntityManager interface. Section 3.5 describes mechanisms for concurrency control and locking. Section 3.12 provides a summary of exceptions.

The EntityManager acts as a factory for instances of Query, which are used to control query execution. Query, TypedQuery, StoredProcedureQuery, and related interfaces are described in Section 3.11. The Jakarta Persistence query language is defined in Chapter 4 and APIs for the construction of Criteria queries in Chapter 6. Section 3.8 describes the use of entity graphs to control and limit the data fetched during find and query operations.

Each EntityManager belongs to an EntityManagerFactory with an associated persistence unit. A persistence unit defines a set of related entities which map to a single database. Entities belonging to the same persistence unit may participate in associations. An EntityManager may only manage instances of entities belonging to its persistence unit. The definition of persistence units is described in Chapter 8. An EntityManagerFactory might have an associated second-level cache. Section 3.10 describes mechanisms for portable configuration of the second-level cache.

Jakarta Persistence features several mechanisms allowing user-written code to react to events occurring within the persistence context. Section 3.6 describes entity listeners and lifecycle callback methods for entities. Section 3.7 describes support for automatic use of Bean Validation. Section 3.8 describes mechanisms for defining conversions between entity and database representations for attributes of basic types.

3.2. EntityManager Interface

The EntityManager interface may be found in Section B.1.

The persist, merge, remove, and refresh methods must be invoked within a transaction context when an entity manager with a transaction-scoped persistence context is used. If there is no transaction context, the jakarta.persistence.TransactionRequiredException is thrown.

Methods that specify a lock mode other than LockModeType.NONE must be invoked within a transaction. If there is no transaction or if the entity manager has not been joined to the transaction, the jakarta.persistence.TransactionRequiredException is thrown.

The find method (provided it is invoked without a lock or invoked with LockModeType.NONE) and the getReference method are not required to be invoked within a transaction. If an entity manager with transaction-scoped persistence context is in use, the resulting entities will be detached; if an entity manager with an extended persistence context is used, they will be managed. See Section 3.4 for entity manager use outside a transaction.

The Query, TypedQuery, StoredProcedureQuery, CriteriaBuilder, Metamodel, and EntityTransaction objects obtained from an entity manager are valid while that entity manager is open.

If the argument to the createQuery method is not a valid Jakarta Persistence query string or a valid CriteriaQuery object, the IllegalArgumentException may be thrown or the query execution will fail and a PersistenceException will be thrown. If the result class specification of a Jakarta Persistence query language query is incompatible with the result of the query, the IllegalArgumentException may be thrown when the createQuery method is invoked or the query execution will fail and a PersistenceException will be thrown when the query is executed. If a native query is not a valid query for the database in use or if the result set specification is incompatible with the result of the query, the query execution will fail and a PersistenceException will be thrown when the query is executed. The PersistenceException should wrap the underlying database exception when possible.

Runtime exceptions thrown by the methods of the EntityManager interface other than the LockTimeoutException will cause the current transaction to be marked for rollback if the persistence context is joined to that transaction.

The methods close, isOpen, joinTransaction, and getTransaction are used to manage application-managed entity managers and their lifecycle. See Section 7.2.2.

The EntityManager interface and other interfaces defined by this specification contain methods that take properties and/or hints as arguments. This specification distinguishes between properties and hints as follows:

  • A property defined by this specification must be observed by the provider unless otherwise explicitly stated.

  • A hint specifies a preference on the part of the application. While a hint defined by this specification should be observed by the provider if possible, a hint may or may not always be observed. A portable application must not depend on the observance of a hint.

For example:

@Stateless
public class OrderEntryBean implements OrderEntry {
    @PersistenceContext
    EntityManager em;

    public void enterOrder(int custID, Order newOrder) {
        Customer cust = em.find(Customer.class, custID);
        cust.getOrders().add(newOrder);
        newOrder.setCustomer(cust);
        em.persist(newOrder);
    }
}

3.3. Entity Instance’s Life Cycle

This section describes the EntityManager operations for managing an entity instance’s lifecycle. An entity instance can be characterized as being new, managed, detached, or removed.

  • A new entity instance has no persistent identity, and is not yet associated with a persistence context.

  • A managed entity instance is an instance with a persistent identity that is currently associated with a persistence context.

  • A detached entity instance is an instance with a persistent identity that is not (or no longer) associated with a persistence context.

  • A removed entity instance is an instance with a persistent identity, associated with a persistence context, that will be removed from the database upon transaction commit.

The following subsections describe the effect of lifecycle operations upon entities. Use of the cascade annotation element may be used to propagate the effect of an operation to associated entities. The cascade functionality is most typically used in parent-child relationships.

3.3.1. Entity Instance Creation

Entity instances are created by means of the new operation. An entity instance, when first created by new is not yet persistent. An instance becomes persistent by means of the EntityManager API.

3.3.2. Persisting an Entity Instance

A new entity instance becomes both managed and persistent by invoking the persist method on it or by cascading the persist operation.

The semantics of the persist operation, applied to an entity X are as follows:

  • If X is a new entity, it becomes managed. The entity X will be entered into the database at or before transaction commit or as a result of the flush operation.

  • If X is a preexisting managed entity, it is ignored by the persist operation. However, the persist operation is cascaded to entities referenced by X, if the relationships from X to these other entities are annotated with the cascade=PERSIST or cascade=ALL annotation element value or specified with the equivalent XML descriptor element.

  • If X is a removed entity, it becomes managed.

  • If X is a detached object, the EntityExistsException may be thrown when the persist operation is invoked, or the EntityExistsException or another PersistenceException may be thrown at flush or commit time.

  • For all entities Y referenced by a relationship from X, if the relationship to Y has been annotated with the cascade element value cascade=PERSIST or cascade=ALL, the persist operation is applied to Y.

3.3.3. Removal

A managed entity instance becomes removed by invoking the remove method on it or by cascading the remove operation.

The semantics of the remove operation, applied to an entity X are as follows:

  • If X is a new entity, it is ignored by the remove operation. However, the remove operation is cascaded to entities referenced by X, if the relationship from X to these other entities is annotated with the cascade=REMOVE or cascade=ALL annotation element value.

  • If X is a managed entity, the remove operation causes it to become removed. The remove operation is cascaded to entities referenced by X, if the relationships from X to these other entities is annotated with the cascade=REMOVE or cascade=ALL annotation element value.

  • If X is a detached entity, an IllegalArgumentException will be thrown by the remove operation (or the transaction commit will fail).

  • If X is a removed entity, it is ignored by the remove operation.

  • A removed entity X will be removed from the database at or before transaction commit or as a result of the flush operation.

After an entity has been removed, its state (except for generated state) will be that of the entity at the point at which the remove operation was called.

3.3.4. Synchronization to the Database

In general, a persistence context will be synchronized to the database as described below. However, a persistence context of type SynchronizationType.UNSYNCHRONIZED or an application-managed persistence context that has been created outside the scope of the current transaction will only be synchronized to the database if it has been joined to the current transaction by the application’s use of the EntityManager.joinTransaction method.

The state of persistent entities is synchronized to the database at transaction commit. This synchronization involves writing to the database any updates to persistent entities and their relationships as specified above.

An update to the state of an entity includes both the assignment of a new value to a persistent property or field of the entity as well as the modification of a mutable value of a persistent property or field[32].

Synchronization to the database does not involve a refresh of any managed entities unless the refresh operation is explicitly invoked on those entities or cascaded to them as a result of the specification of the cascade=REFRESH or cascade=ALL annotation element value.

Bidirectional relationships between managed entities will be persisted based on references held by the owning side of the relationship. It is the developer’s responsibility to keep the in-memory references held on the owning side and those held on the inverse side consistent with each other when they change. In the case of unidirectional one-to-one and one-to-many relationships, it is the developer’s responsibility to ensure that the semantics of the relationships are adhered to.[33]

It is particularly important to ensure that changes to the inverse side of a relationship result in appropriate updates on the owning side, so as to ensure the changes are not lost when they are synchronized to the database.

The persistence provider runtime is permitted to perform synchronization to the database at other times as well when a transaction is active and the persistence context is joined to the transaction. The flush method can be used by the application to force synchronization. It applies to entities associated with the persistence context. The setFlushMode methods of the EntityManager, Query, TypedQuery, and StoredProcedureQuery interfaces can be used to control synchronization semantics. The effect of FlushModeType.AUTO is defined in Section 3.11.2. If FlushModeType.COMMIT is specified, flushing will occur at transaction commit; the persistence provider is permitted, but not required, to perform to flush at other times. If there is no transaction active or if the persistence context has not been joined to the current transaction, the persistence provider must not flush to the database.

The semantics of the flush operation, applied to an entity X are as follows:

  • If X is a managed entity, it is synchronized to the database.

    • For all entities Y referenced by a relationship from X, if the relationship to Y has been annotated with the cascade element value cascade=PERSIST or cascade=ALL, the persist operation is applied to Y.

    • For any entity Y referenced by a relationship from X, where the relationship to Y has not been annotated with the cascade element value cascade=PERSIST or cascade=ALL:

      • If Y is new or removed, an IllegalStateException will be thrown by the flush operation (and the transaction marked for rollback) or the transaction commit will fail.

      • If Y is detached, the semantics depend upon the ownership of the relationship. If X owns the relationship, any changes to the relationship are synchronized with the database; otherwise, if Y owns the relationships, the behavior is undefined.

  • If X is a removed entity, it is removed from the database. No cascade options are relevant.

3.3.5. Refreshing an Entity Instance

The state of a managed entity instance is refreshed from the database by invoking the refresh method on it or by cascading the refresh operation.

The semantics of the refresh operation, applied to an entity X are as follows:

  • If X is a managed entity, the state of X is refreshed from the database, overwriting changes made to the entity, if any. The refresh operation is cascaded to entities referenced by X if the relationship from X to these other entities is annotated with the cascade=REFRESH or cascade=ALL annotation element value.

  • If X is a new, detached, or removed entity, the IllegalArgumentException is thrown.

3.3.6. Evicting an Entity Instance from the Persistence Context

An entity instance is removed from the persistence context by invoking the detach method on it or cascading the detach operation. Changes made to the entity, if any (including removal of the entity), will not be synchronized to the database after such eviction has taken place.

Applications must use the flush method prior to the detach method to ensure portable semantics if changes have been made to the entity (including removal of the entity). Because the persistence provider may write to the database at times other than the explicit invocation of the flush method, portable applications must not assume that changes have not been written to the database if the flush method has not been called prior to detach.

The semantics of the detach operation, applied to an entity X are as follows:

  • If X is a managed entity, the detach operation causes it to become detached. The detach operation is cascaded to entities referenced by X if the relationships from X to these other entities is annotated with the cascade=DETACH or cascade=ALL annotation element value. Entities which previously referenced X will continue to reference X.

  • If X is a new or detached entity, it is ignored by the detach operation.

  • If X is a removed entity, the detach operation causes it to become detached. The detach operation is cascaded to entities referenced by X if the relationships from X to these other entities is annotated with the cascade=DETACH or cascade=ALL annotation element value. Entities which previously referenced X will continue to reference X. Portable applications should not pass removed entities that have been detached from the persistence context to further EntityManager operations.

3.3.7. Detached Entities

A detached entity results from transaction commit if a transaction-scoped persistence context is used (see Section 3.4); from transaction rollback (see Section 3.4.3); from detaching the entity from the persistence context; from clearing the persistence context; from closing an entity manager; or from serializing an entity or otherwise passing an entity by value—e.g., to a separate application tier, through a remote interface, etc.

Detached entity instances continue to live outside the persistence context in which they were persisted or retrieved. Their state is no longer guaranteed to be synchronized with the database state.

The application may access the available state of available detached entity instances after the persistence context ends. The available state includes:

  • Any persistent field or property not marked fetch=LAZY

  • Any persistent field or property that was accessed by the application or fetched by means of an entity graph

If the persistent field or property is an association, the available state of an associated instance may only be safely accessed if the associated instance is available. The available instances include:

  • Any entity instance retrieved using find().

  • Any entity instances retrieved using a query or explicitly requested in a fetch join.

  • Any entity instance for which an instance variable holding non-primary-key persistent state was accessed by the application.

  • Any entity instance that can be reached from another available instance by navigating associations marked fetch=EAGER.

3.3.7.1. Merging Detached Entity State

The merge operation allows for the propagation of state from detached entities onto persistent entities managed by the entity manager.

The semantics of the merge operation applied to an entity X are as follows:

  • If X is a detached entity, the state of X is copied onto a pre-existing managed entity instance X' of the same identity or a new managed copy X' of X is created.

  • If X is a new entity instance, a new managed entity instance X' is created and the state of X is copied into the new managed entity instance X'.

  • If X is a removed entity instance, an IllegalArgumentException will be thrown by the merge operation (or the transaction commit will fail).

  • If X is a managed entity, it is ignored by the merge operation, however, the merge operation is cascaded to entities referenced by relationships from X if these relationships have been annotated with the cascade element value cascade=MERGE or cascade=ALL annotation.

  • For all entities Y referenced by relationships from X having the cascade element value cascade=MERGE or cascade=ALL, Y is merged recursively as Y'. For all such Y referenced by X, X' is set to reference Y'. (Note that if X is managed then X is the same object as X'.)

  • If X is an entity merged to X', with a reference to another entity Y, where cascade=MERGE or cascade=ALL is not specified, then navigation of the same association from X' yields a reference to a managed object Y' with the same persistent identity as Y.

The persistence provider must not merge fields marked LAZY that have not been fetched: it must ignore such fields when merging.

Any Version columns used by the entity must be checked by the persistence runtime implementation during the merge operation and/or at flush or commit time. In the absence of Version columns there is no additional version checking done by the persistence provider runtime during the merge operation.

3.3.7.2. Detached Entities and Lazy Loading

Serializing entities and merging those entities back into a persistence context may not be interoperable across vendors when lazy properties or fields and/or relationships are used.

A vendor is required to support the serialization and subsequent deserialization and merging of detached entity instances (which may contain lazy properties or fields and/or relationships that have not been fetched) back into a separate JVM instance of that vendor’s runtime, where both runtime instances have access to the entity classes and any required vendor persistence implementation classes.

When interoperability across vendors is required, the application must not use lazy loading.

3.3.8. Managed Instances

It is the responsibility of the application to insure that an instance is managed in only a single persistence context. The behavior is undefined if the same Java instance is made managed in more than one persistence context.

The contains() method can be used to determine whether an entity instance is managed in the current persistence context.

The contains method returns true:

  • If the entity has been retrieved from the database or has been returned by getReference, and has not been removed or detached.

  • If the entity instance is new, and the persist method has been called on the entity or the persist operation has been cascaded to it.

The contains method returns false:

  • If the instance is detached.

  • If the remove method has been called on the entity, or the remove operation has been cascaded to it.

  • If the instance is new, and the persist method has not been called on the entity or the persist operation has not been cascaded to it.

Note that the effect of the cascading of persist, merge, remove, or detach is immediately visible to the contains method, whereas the actual insertion, modification, or deletion of the database representation for the entity may be deferred until the end of the transaction.

3.3.9. Load State

An entity is considered to be loaded if all attributes with FetchType.EAGER —whether explictly specified or by default—(including relationship and other collection-valued attributes) have been loaded from the database or assigned by the application. Attributes with FetchType.LAZY may or may not have been loaded. The available state of the entity instance and associated instances is as described in Section 3.3.7.

An attribute that is an embeddable is considered to be loaded if the embeddable attribute was loaded from the database or assigned by the application, and, if the attribute references an embeddable instance (i.e., is not null), the embeddable instance state is known to be loaded (i.e., all attributes of the embeddable with FetchType.EAGER have been loaded from the database or assigned by the application).

A collection-valued attribute is considered to be loaded if the collection was loaded from the database or the value of the attribute was assigned by the application, and, if the attribute references a collection instance (i.e., is not null), each element of the collection (e.g. entity or embeddable) is considered to be loaded.

A single-valued relationship attribute is considered to be loaded if the relationship attribute was loaded from the database or assigned by the application, and, if the attribute references an entity instance (i.e., is not null), the entity instance state is known to be loaded.

A basic attribute is considered to be loaded if its state has been loaded from the database or assigned by the application.

The PersistenceUtil.isLoaded methods can be used to determine the load state of an entity and its attributes regardless of the persistence unit with which the entity is associated. The PersistenceUtil.isLoaded methods return true if the above conditions hold, and false otherwise. If the persistence unit is known, the PersistenceUnitUtil.isLoaded methods can be used instead. See Section 7.11.

Persistence provider contracts for determining the load state of an entity or entity attribute are described in Section 9.9.1.

3.4. Persistence Context Lifetime and Synchronization Type

The lifetime of a container-managed persistence context can either be scoped to a transaction (transaction-scoped persistence context), or have a lifetime scope that extends beyond that of a single transaction (extended persistence context). The enum PersistenceContextType is used to define the persistence context lifetime scope for container-managed entity managers. The persistence context lifetime scope is defined when the EntityManager instance is created (whether explicitly, or in conjunction with injection or JNDI lookup). See Section 7.7.

/**
 * Specifies whether a transaction-scoped or extended persistence
 * context is to be used in {@link PersistenceContext}. If not
 * specified, a transaction-scoped persistence context is used.
 *
 * @since 1.0
 */
public enum PersistenceContextType {

    /** Transaction-scoped persistence context */
    TRANSACTION,

    /** Extended persistence context */
    EXTENDED
}

By default, the lifetime of the persistence context of a container-managed entity manager corresponds to the scope of a transaction (i.e., it is of type PersistenceContextType.TRANSACTION).

When an extended persistence context is used, the extended persistence context exists from the time the EntityManager instance is created until it is closed. This persistence context might span multiple transactions and non-transactional invocations of the EntityManager.

An EntityManager with an extended persistence context maintains its references to the entity objects after a transaction has committed. Those objects remain managed by the EntityManager, and they can be updated as managed objects between transactions.[34] Navigation from a managed object in an extended persistence context results in one or more other managed objects regardless of whether a transaction is active.

When an EntityManager with an extended persistence context is used, the persist, remove, merge, and refresh operations can be called regardless of whether a transaction is active. The effects of these operations will be committed to the database when the extended persistence context is enlisted in a transaction and the transaction commits.

The scope of the persistence context of an application-managed entity manager is extended. It is the responsibility of the application to manage the lifecycle of the persistence context.

Container-managed persistence contexts are described further in Section 7.7. Persistence contexts managed by the application are described further in Section 7.8.

3.4.1. Synchronization with the Current Transaction

By default, a container-managed persistence context is of SynchronizationType.SYNCHRONIZED and is automatically joined to the current transaction. A persistence context of SynchronizationType.UNSYNCHRONIZED will not be enlisted in the current transaction, unless the EntityManager joinTransaction method is invoked.

By default, an application-managed persistence context that is associated with a JTA entity manager and that is created within the scope of an active transaction is automatically joined to that transaction. An application-managed JTA persistence context that is created outside the scope of a transaction or an application-managed persistence context of type SynchronizationType.UNSYNCHRONIZED will not be joined to that transaction unless the EntityManager joinTransaction method is invoked.

An application-managed persistence context associated with a resource-local entity manager is always automatically joined to any resource-local transaction that is begun for that entity manager.

Persistence context synchronization type is described further in Section 7.7.1.

3.4.2. Transaction Commit

The managed entities of a transaction-scoped persistence context become detached when the transaction commits; the managed entities of an extended persistence context remain managed.

3.4.3. Transaction Rollback

For both transaction-scoped persistence contexts and for extended persistence contexts that are joined to the current transaction, transaction rollback causes all pre-existing managed instances and removed instances[35] to become detached. The instances' state will be the state of the instances at the point at which the transaction was rolled back. Transaction rollback typically causes the persistence context to be in an inconsistent state at the point of rollback. In particular, the state of version attributes and generated state (e.g., generated primary keys) may be inconsistent. Instances that were formerly managed by the persistence context (including new instances that were made persistent in that transaction) may therefore not be reusable in the same manner as other detached objects—for example, they may fail when passed to the merge operation.[36]

Because a transaction-scoped persistence context’s lifetime is scoped to a transaction regardless of whether it is joined to that transaction, the container closes the persistence context upon transaction rollback. However, an extended persistence context that is not joined to a transaction is unaffected by transaction rollback.

3.5. Locking and Concurrency

This specification assumes the use of optimistic concurrency control. It assumes that the databases to which persistence units are mapped will be accessed by the implementation using read-committed isolation (or a vendor equivalent in which long-term read locks are not held), and that writes to the database will typically occur only when the flush method has been invoked—whether explicitly by the application, or by the persistence provider runtime in accordance with the flush mode setting.

If a transaction is active and the persistence context is joined to the transaction, a compliant implementation of this specification is permitted to write to the database immediately (i.e., whenever a managed entity is updated, created, and/or removed), however, the configuration of an implementation to require such non-deferred database writes is outside the scope of this specification.[37]

In addition, both pessimistic and optimistic locking are supported for selected entities by means of specified lock modes. Optimistic locking is described in Section 3.5.1 and Section 3.5.2; pessimistic locking in Section 3.5.3. Section 3.5.4 describes the setting of optimistic and pessimistic lock modes. The configuration of the setting of optimistic lock modes is described in Section 3.5.4.1, and the configuration of the setting of pessimistic lock modes is described in Section 3.5.4.2.

3.5.1. Optimistic Locking

Optimistic locking is a system of concurrency control where each revision of an item of data is assigned a version number or timestamp. When the data is read and then updated within a given unit of work, the version or timestamp is:

  1. read from the database when the data itself is read, and

  2. verified and then updated in the database when the data is updated.

Similarly, when the data is read and then deleted within a given unit of work, the version or timestamp is:

  1. read from the database when the data itself is read, and

  2. verified when the data is deleted.

An optimistic lock failure occurs when verification fails, that is, if the version or timestamp held in the database changes between reading the data (step 1), and attempting to update or delete the data (step 2).

Thus, the unit of work is prevented from updating the data and creating a new revision, or from deleting the data, unless the revision it previously obtained is still the current revision. Optimistic lock verification ensures that an update of a given item is successful only when no intervening transaction has already updated the item, preventing the loss of updates made by such intervening transactions.

The persistence provider is required to perform optimistic locking automatically for every entity with a version, as defined in Section 2.5. A portable application which wishes to take advantage of automatic optimistic locking must specify a version field or property for each optimistically-locked entity using the @Version annotation defined in Section 11.1.57 or equivalent XML element.

When an optimistic lock failure is detected, the persistence provider must:

  • throw an OptimisticLockException and

  • mark the current transaction for rollback.

A persistence provider might offer alternative implementations of optimistic locking, which do not depend on the entity having a version, but such functionality is not portable between providers.[38]

Applications are strongly encouraged to enable optimistic locking for every entity which may be concurrently accessed or which may be merged from a detached state. Failure to make use of optimistic locking often leads to inconsistent entity state, lost updates, and other anomalies. If an entity does not have a version, the application itself must bear the burden of maintaining data consistency during optimistic units of work.

For the purposes of versioning and optimistic locking, the state of a given entity is considered to include:

  • every persistent field or property which is not a relationship to another entity, and

  • every relationship owned by the entity, as defined by Section 2.11. [39]

Unowned relationships are not considered part of the state of the entity.

3.5.2. Entity Versions and Optimistic Locking

The entity version must be updated by the persistence provider each time the state of an entity instance is written to the database. [40] Furthermore, if the current persistence context contains a revision of the entity instance when the instance is written to the database, the persistence provider must verify that the revision held in the persistence context is identical to the revision held in the database by comparing the versions held in memory and in the database. [41] If the versions do not match, the persistence provider must thow an OptimisticLockException.

The persistence provider must examine the version field or property of a detached entity instance when it is merged, as defined in Section 3.3.7.1, and throw an OptimisticLockException if the instance being merged holds a stale revision of the state of the entity—​that is, if the entity was updated since the entity instance became detached. The timing of this version check is provider-dependent:

  • the version check might occur synchronously with the call to merge(), or

  • a provider might choose to delay the version check until a flush operation occurs, as defined in Section 3.3.4, or until the transaction commits.

If an update or merge operation involves entities with versions, and entities without versions, the persistence provider runtime is only required to perform optimistic lock verification for those entities which do have a version, and the consistency of the whole object graph is not guaranteed. The absence a version for some entity involved in the update or merge operation does not impede completion of the operation.

3.5.3. Pessimistic Locking

While optimistic locking is typically appropriate in dealing with moderate contention among concurrent transactions, in some applications it may be useful to immediately obtain long-term database locks for selected entities because of the often late failure of optimistic transactions. Such immediately obtained long-term database locks are referred to here as “pessimistic” locks.[42]

Pessimistic locking guarantees that once a transaction has obtained a pessimistic lock on an entity instance:

  • no other transaction (whether a transaction of an application using the Jakarta Persistence API or any other transaction using the underlying resource) may successfully modify or delete that instance until the transaction holding the lock has ended.

  • if the pessimistic lock is an exclusive lock[43], that same transaction may modify or delete that entity instance.

When an entity instance is locked using pessimistic locking, the persistence provider must lock the database row(s) that correspond to the non-collection-valued persistent state of that instance. If a joined inheritance strategy is used, or if the entity is otherwise mapped to a secondary table, this entails locking the row(s) for the entity instance in the additional table(s). Entity relationships for which the locked entity contains the foreign key will also be locked, but not the state of the referenced entities (unless those entities are explicitly locked). Element collections and relationships for which the entity does not contain the foreign key (such as relationships that are mapped to join tables or unidirectional one-to-many relationships for which the target entity contains the foreign key) will not be locked by default.

Element collections and relationships owned by the entity that are contained in join tables will be locked if the jakarta.persistence.lock.scope property is specified with a value of PessimisticLockScope.EXTENDED. The state of entities referenced by such relationships will not be locked (unless those entities are explicitly locked). This property may be passed as an argument to the methods of the EntityManager, Query, and TypedQuery interfaces that allow lock modes to be specified or used with the NamedQuery annotation.

Locking such a relationship or element collection generally locks only the rows in the join table or collection table for that relationship or collection. This means that phantoms will be possible.

The values of the jakarta.persistence.lock.scope property are defined by the PessimisticLockScope enum.

/**
 *
 * Defines the values of the {@code jakarta.persistence.lock.scope}
 * property for pessimistic locking.  This property may be passed as an
 * argument to the methods of the {@link EntityManager}, {@link Query},
 * and {@link TypedQuery} interfaces that allow lock modes to be specified
 * or used with the {@link NamedQuery} annotation.
 *
 * @since 2.0
 */
public enum PessimisticLockScope implements FindOption, RefreshOption, LockOption {

    /**
     * This value defines the default behavior for pessimistic locking.
     *
     * <p>The persistence provider must lock the database row(s) that
     * correspond to the non-collection-valued persistent state of
     * that instance. If a joined inheritance strategy is used, or if
     * the entity is otherwise mapped to a secondary table, this
     * entails locking the row(s) for the entity instance in the
     * additional table(s). Entity relationships for which the locked
     * entity contains the foreign key will also be locked, but not
     * the state of the referenced entities (unless those entities are
     * explicitly locked). Element collections and relationships for
     * which the entity does not contain the foreign key (such as
     * relationships that are mapped to join tables or unidirectional
     * one-to-many relationships for which the target entity contains
     * the foreign key) will not be locked by default.
     */
    NORMAL,

    /**
     * In addition to the locking behavior specified for {@link #NORMAL},
     * element collections and relationships owned by the entity that
     * are contained in join tables are locked if the property
     * {@code jakarta.persistence.lock.scope} is specified with a value
     * of {@code PessimisticLockScope#EXTENDED}. The state of entities
     * referenced by such relationships is not locked (unless those
     * entities are explicitly locked). Locking such a relationship or
     * element collection generally locks only the rows in the join table
     * or collection table for that relationship or collection. This means
     * that phantoms are possible.
     */
    EXTENDED
}

This specification does not define the mechanisms a persistence provider uses to obtain database locks, and a portable application should not rely on how pessimistic locking is achieved on the database.[44] In particular, a persistence provider or the underlying database management system may lock more rows than the ones selected by the application.

Whenever a pessimistically locked entity containing a version attribute is updated on the database, the persistence provider must also update (increment) the entity’s version column to enable correct interaction with applications using optimistic locking. See Section 3.5.2 and Section 3.5.4.

Pessimistic locking may be applied to entities that do not contain version attributes. However, in this case correct interaction with applications using optimistic locking cannot be ensured.

3.5.4. Lock Modes

Lock modes are intended to provide a facility that enables the effect of “repeatable read” semantics for the items read, whether “optimistically” (as described in Section 3.5.4.1) or “pessimistically” (as described in Section 3.5.4.2).

A lock mode may be explicitly specified as an argument to the lock() method of EntityManager or to any other method of EntityManager, Query, and TypedQuery which accepts a lock mode, or via the NamedQuery annotation.

Lock mode values are defined by the LockModeType enum which may be found in Section B.4. Six distinct lock modes are defined. [45] The lock mode type values READ and WRITE are synonyms for OPTIMISTIC and OPTIMISTIC_FORCE_INCREMENT respectively. The latter are to be preferred for new applications.

3.5.4.1. OPTIMISTIC, OPTIMISTIC_FORCE_INCREMENT

The lock modes OPTIMISTIC and OPTIMISTIC_FORCE_INCREMENT are used for optimistic locking. The lock mode type values READ and WRITE are synonymous with OPTIMISTIC and OPTIMISTIC_FORCE_INCREMENT respectively.

The semantics of requesting locks of type LockModeType.OPTIMISTIC and LockModeType.OPTIMISTIC_FORCE_INCREMENT are the following.

If transaction T1 calls lock(entity, LockModeType.OPTIMISTIC) on a versioned object, the entity manager must ensure that neither of the following phenomena can occur:

  • P1 (Dirty read): Transaction T1 modifies a row. Another transaction T2 then reads that row and obtains the modified value, before T1 has committed or rolled back. Transaction T2 eventually commits successfully; it does not matter whether T1 commits or rolls back and whether it does so before or after T2 commits.

  • P2 (Non-repeatable read): Transaction T1 reads a row. Another transaction T2 then modifies or deletes that row, before T1 has committed. Both transactions eventually commit successfully.

This will generally be achieved by the entity manager acquiring a lock on the underlying database row. While with optimistic concurrency concurrency, long-term database read locks are typically not obtained immediately, a compliant implementation is permitted to obtain an immediate lock (so long as it is retained until commit completes). If the lock is deferred until commit time, it must be retained until the commit completes. Any implementation that supports repeatable reads in a way that prevents the above phenomena is permissible.

The persistence implementation is not required to support calling lock(entity, LockModeType.OPTIMISTIC) on a non-versioned object. When it cannot support such a lock call, it must throw the PersistenceException. When supported, whether for versioned or non-versioned objects, LockModeType.OPTIMISTIC must always prevent the phenomena P1 and P2. Applications that call lock(entity, LockModeType.OPTIMISTIC) on non-versioned objects are not portable.

If transaction T1 calls lock(entity, LockModeType.OPTIMISTIC_FORCE_INCREMENT) on a versioned object, the entity manager must avoid the phenomena P1 and P2 (as with LockModeType.OPTIMISTIC) and must also force an update (increment) to the entity’s version column. A forced version update may be performed immediately, or may be deferred until a flush or commit. If an entity is removed before a deferred version update was to have been applied, the forced version update is omitted.

The persistence implementation is not required to support calling lock(entity, LockModeType.OPTIMISTIC_FORCE_INCREMENT) on a non-versioned object. When it cannot support such a lock call, it must throw the PersistenceException. When supported, whether for versioned or non-versioned objects, LockModeType.OPTIMISTIC_FORCE_INCREMENT must always prevent the phenomena P1 and P2. For non-versioned objects, whether or not LockModeType.OPTIMISTIC_FORCE_INCREMENT has any additional behavior is vendor-specific. Applications that call lock(entity, LockModeType.OPTIMISTIC_FORCE_INCREMENT) on non-versioned objects will not be portable.

For versioned objects, it is permissible for an implementation to use LockModeType.OPTIMISTIC_FORCE_INCREMENT where LockModeType.OPTIMISTIC was requested, but not vice versa.

If a versioned object is otherwise updated or removed, then the implementation must ensure that the requirements of LockModeType.OPTIMISTIC_FORCE_INCREMENT are met, even if no explicit call to EntityManager.lock was made.

For portability, an application should not depend on vendor-specific hints or configuration to ensure repeatable read for objects that are not updated or removed via any mechanism other than the use of version attributes and the EntityManager lock method. However, it should be noted that if an implementation has acquired up-front pessimistic locks on some database rows, then it is free to ignore lock(entity, LockModeType.OPTIMISTIC) calls on the entity objects representing those rows.

3.5.4.2. PESSIMISTIC_READ, PESSIMISTIC_WRITE, PESSIMISTIC_FORCE_INCREMENT

The lock modes PESSIMISTIC_READ, PESSIMISTIC_WRITE, and PESSIMISTIC_FORCE_INCREMENT are used to immediately obtain long-term database locks.[46]

The semantics of requesting locks of type LockModeType.PESSIMISTIC_READ, LockModeType.PESSIMISTIC_WRITE, and LockModeType.PESSIMISTIC_FORCE_INCREMENT are the following.

If transaction T1 calls lock(entity, LockModeType.PESSIMISTIC_READ) or lock(entity, LockModeType.PESSIMISTIC_WRITE) on an object, the entity manager must ensure that neither of the following phenomena can occur:

  • P1 (Dirty read): Transaction T1 modifies a row. Another transaction T2 then reads that row and obtains the modified value, before T1 has committed or rolled back.

  • P2 (Non-repeatable read): Transaction T1 reads a row. Another transaction T2 then modifies or deletes that row, before T1 has committed or rolled back.

Any such lock must be obtained immediately and retained until transaction T1 completes (commits or rolls back).

Avoidance of phenomena P1 and P2 is generally achieved by the entity manager acquiring a long-term lock on the underlying database row(s). Any implementation that supports pessimistic repeatable reads as described above is permissible.

A lock with LockModeType.PESSIMISTIC_WRITE can be obtained on an entity instance to force serialization among transactions attempting to update the entity data. A lock with LockModeType.PESSIMISTIC_READ can be used to query data using repeatable-read semantics without the need to reread the data at the end of the transaction to obtain a lock, and without blocking other transactions reading the data. A lock with LockModeType.PESSIMISTIC_WRITE can be used when querying data and there is a high likelihood of deadlock or update failure among concurrent updating transactions.

The persistence implementation must support calling lock(entity, LockModeType.PESSIMISTIC_READ) and lock(entity, LockModeType.PESSIMISTIC_WRITE) on a non-versioned entity as well as on a versioned entity.

It is permissible for an implementation to use LockModeType.PESSIMISTIC_WRITE where LockModeType.PESSIMISTIC_READ was requested, but not vice versa.

When the lock cannot be obtained, and the database locking failure results in transaction-level rollback, the provider must throw the PessimisticLockException and ensure that the JTA transaction or EntityTransaction has been marked for rollback.

When the lock cannot be obtained, and the database locking failure results in only statement-level rollback, the provider must throw the LockTimeoutException (and must not mark the transaction for rollback).

When an application locks an entity with LockModeType.PESSIMISTIC_READ and later updates that entity, the lock must be converted to an exclusive lock when the entity is flushed to the database.[47] If the lock conversion fails, and the database locking failure results in transaction-level rollback, the provider must throw the PessimisticLockException and ensure that the JTA transaction or EntityTransaction has been marked for rollback. When the lock conversion fails, and the database locking failure results in only statement-level rollback, the provider must throw the LockTimeoutException (and must not mark the transaction for rollback).

When lock(entity, LockModeType.PESSIMISTIC_READ), lock(entity, LockModeType.PESSIMISTIC_WRITE), or lock(entity, LockModeType.PESSIMISTIC_FORCE_INCREMENT) is invoked on a versioned entity that is already in the persistence context, the provider must also perform optimistic version checks when obtaining the lock. An OptimisticLockException must be thrown if the version checks fail. Depending on the implementation strategy used by the provider, it is possible that this exception may not be thrown until flush is called or commit time, whichever occurs first.

If transaction T1 calls lock(entity, LockModeType.PESSIMISTIC_FORCE_INCREMENT) on a versioned object, the entity manager must avoid the phenomenon P1 and P2 (as with LockModeType.PESSIMISTIC_READ and LockModeType.PESSIMISTIC_WRITE) and must also force an update (increment) to the entity’s version column.

The persistence implementation is not required to support calling lock(entity, LockModeType.PESSIMISTIC_FORCE_INCREMENT) on a non-versioned object. When it cannot support such a lock call, it must throw the PersistenceException. When supported, whether for versioned or non-versioned objects, LockModeType.PESSIMISTIC_FORCE_INCREMENT must always prevent the phenomena P1 and P2. For non-versioned objects, whether or not LockModeType.PESSIMISTIC_FORCE_INCREMENT has any additional behavior is vendor-specific. Applications that call lock(entity, LockModeType.PESSIMISTIC_FORCE_INCREMENT) on non-versioned objects will not be portable.

For versioned objects, it is permissible for an implementation to use LockModeType.PESSIMISTIC_FORCE_INCREMENT where LockModeType.PESSIMISTIC_READ or LockModeType.PESSIMISTIC_WRITE was requested, but not vice versa.

If a versioned object locked with LockModeType.PESSIMISTIC_READ or LockModeType.PESSIMISTIC_WRITE is updated, then the implementation must ensure that the requirements of LockModeType.PESSIMISTIC_FORCE_INCREMENT are met.

3.5.4.3. Lock Mode Properties and Uses

The following property is defined by this specification for use in pessimistic locking, as described in Section 3.5.3:

jakarta.persistence.lock.scope

This property may be used with the methods of the EntityManager interface that allow lock modes to be specified, the Query and TypedQuery setLockMode methods, and the NamedQuery annotation. When specified, this property must be observed. The provider is permitted to lock more (but not fewer) rows than requested.

The following hint is defined by this specification for use in pessimistic locking.

jakarta.persistence.lock.timeout // time in milliseconds

This hint may be used with the methods of the EntityManager interface that allow lock modes to be specified, the Query.setLockMode method and the NamedQuery annotation. It may also be passed as a property to the Persistence.createEntityManagerFactory method and used in the properties element of the persistence.xml file. See Section 3.2, Section 3.11.3, Section 8.2.1.11, Section 9.7, and Section 10.4.1. When used in the createEntityManagerFactory method, the persistence.xml file, and the NamedQuery annotation, the timeout hint serves as a default value which can be selectively overridden by use in the methods of the EntityManager, Query, and TypedQuery interfaces as specified above. When this hint is not specified, database timeout values are assumed to apply.

A timeout value of 0 is used to specify “no wait” locking.

Portable applications should not rely on this hint. Depending on the database in use and the locking mechanisms used by the persistence provider, the hint may or may not be observed.

Vendors are permitted to support the use of additional, vendor-specific locking hints. Vendor-specific hints must not use the jakarta.persistence namespace. Vendor-specific hints must be ignored if they are not understood.

If the same property or hint is specified more than once, the following order of overriding applies, in order of decreasing precedence:

  • argument to method of EntityManager, Query, or TypedQuery interface

  • specification to NamedQuery (annotation or XML)

  • argument to createEntityManagerFactory method

  • specification in persistence.xml

3.5.5. OptimisticLockException

Provider implementations may defer writing to the database until the end of the transaction, when consistent with the lock mode and flush mode settings in effect. In this case, an optimistic lock check may not occur until commit time, and the OptimisticLockException may be thrown in the “before completion” phase of the commit. If the OptimisticLockException must be caught or handled by the application, the flush method should be used by the application to force the database writes to occur. This will allow the application to catch and handle optimistic lock exceptions.

The OptimisticLockException provides an API to return the object that caused the exception to be thrown. The object reference is not guaranteed to be present every time the exception is thrown but should be provided whenever the persistence provider can supply it. Applications cannot rely upon this object being available.

In some cases an OptimisticLockException will be thrown and wrapped by another exception, such as a RemoteException, when VM boundaries are crossed. Entities that may be referenced in wrapped exceptions should implement Serializable so that marshalling will not fail.

An OptimisticLockException always causes the transaction to be marked for rollback.

Refreshing objects or reloading objects in a new transaction context and then retrying the transaction is a potential response to an OptimisticLockException.

3.6. Entity Listeners and Callback Methods

A method may be designated as a lifecycle callback method to receive notification of entity lifecycle events. A lifecycle callback method can be defined on an entity class, a mapped superclass, or an entity listener class associated with an entity or mapped superclass. An entity listener class is a class whose methods are invoked in response to lifecycle events on an entity. Any number of entity listener classes can be defined for an entity class or mapped superclass.

Default entity listeners—entity listener classes whose callback methods apply to all entities in the persistence unit—can be specified by means of the XML descriptor.

Lifecycle callback methods and entity listener classes are defined by means of metadata annotations or the XML descriptor. When annotations are used, one or more entity listener classes are denoted using the EntityListeners annotation on the entity class or mapped superclass. If multiple entity listeners are defined, the order in which they are invoked is determined by the order in which they are specified in the EntityListeners annotation. The XML descriptor may be used as an alternative to specify the invocation order of entity listeners or to override the order specified in metadata annotations.

Any subset or combination of annotations may be specified on an entity class, mapped superclass, or listener class. A single class must not have more than one lifecycle callback method for the same lifecycle event. The same method may be used for multiple callback events.

Multiple entity classes and mapped superclasses in an inheritance hierarchy may define listener classes and/or lifecycle callback methods directly on the class. Section 3.6.4 describes the rules that apply to method invocation order in this case.

3.6.1. Entity Listeners

The entity listener class must have a public no-arg constructor.

Entity listener classes in Jakarta EE environments support dependency injection through the Contexts and Dependency Injection API (CDI) [7] when CDI is enabled[48]. An entity listener class that makes use of CDI injection may also define lifecycle callback methods annotated with the PostConstruct and PreDestroy annotations. These methods will be invoked after injection has taken place and before the entity listener instance is destroyed respectively.

The persistence provider is responsible for using the CDI SPI to create instances of the entity listener class; to perform injection upon such instances; to invoke their PostConstruct and PreDestroy methods, if any; and to dispose of the entity listener instances.

The persistence provider is only required to support CDI injection into entity listeners in Jakarta EE container environments[49]. If the CDI is not enabled, the persistence provider must not invoke entity listeners that depend upon CDI injection.

An entity listener is a noncontextual object. In supporting injection into entity listeners, the persistence provider must behave as if it carries out the following steps involving the use of the CDI SPI. (See [7]).

  • Obtain a BeanManager instance. (See Section 9.1)

  • Create an AnnotatedType instance for the entity listener class.

  • Create an InjectionTarget instance for the annotated type.

  • Create a CreationalContext.

  • Instantiate the listener by calling the InjectionTarget produce method.

  • Inject the listener instance by calling the InjectionTarget inject method on the instance.

  • Invoke the PostConstruct callback, if any, by calling the InjectionTarget postConstruct method on the instance.

When the listener instance is to be destroyed, the persistence provider must behave as if it carries out the following steps.

  • Call the InjectionTarget preDestroy method on the instance.

  • Call the InjectionTarget dispose method on the instance

  • Call the CreationalContext release method.

Persistence providers may optimize the steps above, e.g. by avoiding calls to the actual CDI SPI and relying on container-specific interfaces instead, as long as the outcome is the same.

Entity listeners that do not make use of CDI injection are stateless. The lifecycle of such entity listeners is unspecified.

When invoked from within a Jakarta EE environment, the callback listeners for an entity share the enterprise naming context of the invoking component, and the entity callback methods are invoked in the transaction and security contexts of the calling component at the time at which the callback method is invoked. [50]

3.6.2. Lifecycle Callback Methods

Entity lifecycle callback methods can be defined on an entity listener class and/or directly on an entity class or mapped superclass.

A lifecycle callback method must be either:

  • annotated with annotations designating the callback events for which it is invoked, or

  • mapped to a callback event type using the XML descriptor.

The same annotations (and XML elements) are used to declare:

  • callback methods of an entity class or mapped superclass, and

  • callback methods of an entity listener class.

The signatures of the callback methods differ between these two cases:

  • a callback method defined by an entity class or mapped superclass has the signature:

    void <METHOD>()
  • a callback method defined by an entity listener class has the signature:

    void <METHOD>(S)

    where S is any supertype of the entity class or mapped superclass to which the entity listener is applied. At runtime, the argument to the entity listener callback method is the entity instance for which the callback method is being invoked.

Callback methods can have public, private, protected, or package level access, but must not be static or final.

The following annotations designate lifecycle event callback methods of the corresponding types.

  • PrePersist

  • PostPersist

  • PreRemove

  • PostRemove

  • PreUpdate

  • PostUpdate

  • PostLoad

The following rules apply to lifecycle callback methods:

  • Lifecycle callback methods may throw unchecked/runtime exceptions. A runtime exception thrown by a callback method that executes within a transaction causes that transaction to be marked for rollback if the persistence context is joined to the transaction.

  • Lifecycle callbacks can invoke JNDI, JDBC, JMS, and enterprise beans.

  • A lifecycle callback method may modify the non-relationship state of the entity on which it is invoked.

  • In general, the lifecycle method of a portable application should not invoke EntityManager or query operations, access other entity instances, or modify relationships within the same persistence context[51].

3.6.3. Semantics of the Life Cycle Callback Methods for Entities

The PrePersist and PreRemove callback methods are invoked for a given entity before the respective EntityManager persist and remove operations for that entity are executed. For entities to which the merge operation has been applied and causes the creation of newly managed instances, the PrePersist callback methods will be invoked for the managed instance after the entity state has been copied to it. These PrePersist and PreRemove callbacks will also be invoked on all entities to which these operations are cascaded. The PrePersist and PreRemove methods will always be invoked as part of the synchronous persist, merge, and remove operations. Primary key values generated using the SEQUENCE, TABLE, or UUID strategy are available in the PrePersist method. Primary key values generated using the IDENTITY strategy are not available in the PrePersist method.

The PostPersist and PostRemove callback methods are invoked for an entity after the entity has been made persistent or removed. These callbacks will also be invoked on all entities to which these operations are cascaded. The PostPersist and PostRemove methods will be invoked after the database insert and delete operations respectively. These database operations may occur directly after the persist, merge, or remove operations have been invoked or they may occur directly after a flush operation has occurred (which may be at the end of the transaction). Generated primary key values are always available in the PostPersist method.

The PreUpdate and PostUpdate callbacks occur before and after the database update operations to entity data respectively. These database operations may occur at the time the entity state is updated or they may occur at the time state is flushed to the database (which may be at the end of the transaction).

Note that it is implementation-dependent as to whether PreUpdate and PostUpdate callbacks occur when an entity is persisted and subsequently modified in a single transaction or when an entity is modified and subsequently removed within a single transaction. Portable applications should not rely on such behavior.

The PostLoad method for an entity is invoked after the entity has been loaded into the current persistence context from the database or after the refresh operation has been applied to it. The PostLoad method is invoked before a query result is returned or accessed or before an association is traversed.

It is implementation-dependent as to whether callback methods are invoked before or after the cascading of the lifecycle events to related entities. Applications should not depend on this ordering.

For example:

@Entity
@EntityListeners(com.acme.AlertMonitor.class)
public class Account {
    Long accountId;
    Integer balance;
    boolean preferred;

    @Id
    public Long getAccountId() { ... }

    // ...

    public Integer getBalance() { ... }

    // ...

    @Transient // because status depends upon non-persistent context
    public boolean isPreferred() { ... }

    // ...

    public void deposit(Integer amount) { ... }

    public Integer withdraw(Integer amount) throws NSFException { ... }

    @PrePersist
    protected void validateCreate() {
        if (getBalance() < MIN_REQUIRED_BALANCE)
            throw new AccountException("Insufficient balance to open an account");
    }

    @PostLoad
    protected void adjustPreferredStatus() {
        preferred = (getBalance() >= AccountManager.getPreferredStatusLevel());
    }
}

public class AlertMonitor {
    @PostPersist
    public void newAccountAlert(Account acct) {
        Alerts.sendMarketingInfo(acct.getAccountId(), acct.getBalance());
    }
}

3.6.4. Multiple Lifecycle Callback Methods for an Entity Lifecycle Event

If multiple callback methods are defined for an entity lifecycle event, the ordering of the invocation of these methods is as follows.

Default listeners, if any, are invoked first, in the order specified in the XML descriptor. Default listeners apply to all entities in the persistence unit, unless explicitly excluded by means of the ExcludeDefaultListeners annotation or exclude-default-listeners XML element.

The lifecycle callback methods defined on the entity listener classes for an entity class or mapped superclass are invoked in the same order as the specification of the entity listener classes in the EntityListeners annotation.

If multiple classes in an inheritance hierarchy—entity classes and/or mapped superclasses—define entity listeners, the listeners defined for a superclass are invoked before the listeners defined for its subclasses in this order. The ExcludeSuperclassListeners annotation or exclude-superclass-listeners XML element may be applied to an entity class or mapped superclass to exclude the invocation of the listeners defined by the entity listener classes for the superclasses of the entity or mapped superclass. The excluded listeners are excluded from the class to which the ExcludeSuperclassListeners annotation or element has been specified and its subclasses[52]. The ExcludeSuperclassListeners annotation (or exclude-superclass-listeners XML element) does not cause default entity listeners to be excluded from invocation.

If a lifecycle callback method for the same lifecycle event is also specified on the entity class and/or one or more of its entity or mapped superclasses, the callback methods on the entity class and/or superclasses are invoked after the other lifecycle callback methods, most general superclass first. A class is permitted to override an inherited callback method of the same callback type, and in this case, the overridden method is not invoked[53].

Callback methods are invoked by the persistence provider runtime in the order specified. If the callback method execution terminates normally, the persistence provider runtime then invokes the next callback method, if any.

The XML descriptor may be used to override the lifecycle callback method invocation order specified in annotations.

For example:

There are several entity classes and listeners for animals:

@Entity
public class Animal {

    // ...

    @PostPersist
    protected void postPersistAnimal() {
        // ...
    }
}

@Entity
@EntityListeners(PetListener.class)
public class Pet extends Animal {
    // ...
}

@Entity
@EntityListeners({CatListener.class, CatListener2.class})
public class Cat extends Pet {
    // ...
}

public class PetListener {
    @PostPersist
    protected void postPersistPetListenerMethod(Object pet) {
        // ...
    }
}

public class CatListener {
    @PostPersist
    protected void postPersistCatListenerMethod(Object cat) {
        // ...
    }
}

public class CatListener2 {
    @PostPersist
    protected void postPersistCatListener2Method(Object cat) {
        // ...
    }
}

If a PostPersist event occurs on an instance of Cat, the following methods are called in order:

  1. postPersistPetListenerMethod

  2. postPersistCatListenerMethod

  3. postPersistCatListener2Method

  4. postPersistAnimal

Assume that SiameseCat is defined as a subclass of Cat:

@EntityListeners(SiameseCatListener.class)
@Entity
public class SiameseCat extends Cat {
    // ...

    @PostPersist
    protected void postPersistSiameseCat() {
        // ...
    }
}

public class SiameseCatListener {
    @PostPersist
    protected void postPersistSiameseCatListenerMethod(Object cat) {
        // ...
    }
}

If a PostPersist event occurs on an instance of SiameseCat, the following methods are called in order:

  1. postPersistPetListenerMethod

  2. postPersistCatListenerMethod

  3. postPersistCatListener2Method

  4. postPersistSiameseCatListenerMethod

  5. postPersistAnimal

  6. postPersistSiameseCat

Assume the definition of SiameseCat were instead:

@EntityListeners(SiameseCatListener.class)
@Entity
public class SiameseCat extends Cat {
    // ...

    @PostPersist
    protected void postPersistAnimal() {
        // ...
    }
}

In this case, the following methods would be called in order, where postPersistAnimal is the PostPersist method defined in the SiameseCat class:

  1. postPersistPetListenerMethod

  2. postPersistCatListenerMethod

  3. postPersistCatListener2Method

  4. postPersistSiameseCatListenerMethod

  5. postPersistAnimal

3.6.5. Exceptions

Lifecycle callback methods may throw runtime exceptions. A runtime exception thrown by a callback method that executes within a transaction causes that transaction to be marked for rollback if the persistence context is joined to the transaction. No further lifecycle callback methods will be invoked after a runtime exception is thrown.

3.6.6. Specification of Callback Listener Classes and Lifecycle Methods in the XML Descriptor

The XML descriptor can be used as an alternative to metadata annotations to specify entity listener classes and their binding to entities or to override the invocation order of lifecycle callback methods as specified in annotations.

3.6.6.1. Specification of Callback Listeners

The entity-listener XML descriptor element is used to specify the lifecycle listener methods of an entity listener class. The lifecycle listener methods are specified by using the pre-persist, post-persist, pre-remove, post-remove, pre-update, post-update, and/or post-load elements.

An entity listener class can define multiple callback methods. However, at most one method of an entity listener class can be designated as a pre-persist method, post-persist method, pre-remove method, post-remove method, pre-update method, post-update method, and/or post-load method, regardless of whether the XML descriptor is used to define entity listeners or whether some combination of annotations and XML descriptor elements is used.

3.6.6.2. Specification of the Binding of Entity Listener Classes to Entities

The entity-listeners subelement of the persistence-unit-defaults element is used to specify the default entity listeners for the persistence unit.

The entity-listeners subelement of the entity or mapped-superclass element is used to specify the entity listener classes for the respective entity or mapped superclass and its subclasses.

The binding of entity listeners to entity classes is additive. The entity listener classes bound to the superclasses of an entity or mapped superclass are applied to it as well.

The exclude-superclass-listeners element specifies that the listener methods for superclasses are not to be invoked for an entity class (or mapped superclass) and its subclasses.

The exclude-default-listeners element specifies that default entity listeners are not to be invoked for an entity class (or mapped superclass) and its subclasses.

Explicitly listing an excluded default or superclass listener for a given entity class or mapped superclass causes it to be applied to that entity or mapped superclass and its subclasses.

In the case of multiple callback methods for a single lifecycle event, the invocation order rules described in Section 3.6.4 apply.

3.7. Bean Validation

This specification defines support for use of Bean Validation [5] within Jakarta Persistence applications.

Managed classes (entities, mapped superclasses, and embeddable classes) may be configured to include Bean Validation constraints.

Automatic validation using these constraints is achieved by specifying that Jakarta Persistence delegate validation to the Bean Validation implementation upon the pre-persist, pre-update, and pre-remove entity lifecycle events described in Section 3.6.3.

Validation can also be achieved by the application calling the validate method of a Validator instance upon an instance of a managed class, as described in the Bean Validation specification [5].

3.7.1. Automatic Validation Upon Lifecycle Events

This specification supports the use of bean validation for the automatic validation of entities upon the pre-persist, pre-update, and pre-remove lifecycle validation events. These lifecycle validation events occur immediately after the point at which all the PrePersist, PreUpdate, and PreRemove lifecycle callback method invocations respectively have been completed, or immediately after the point at which such lifecycle callback methods would have been completed (in the event that such callback methods are not present).

In the case where an entity is persisted and subsequently modified in a single transaction or when an entity is modified and subsequently removed in a single transaction, it is implementation dependent as to whether the pre-update validation event occurs. Portable applications should not rely on this behavior.

3.7.1.1. Enabling Automatic Validation

The validation-mode element of the persistence.xml file determines whether the automatic lifecycle event validation is in effect. The values of the validation-mode element are AUTO, CALLBACK, NONE. The default validation mode is AUTO.

If the application creates the entity manager factory using the Persistence.createEntityManagerFactory method, the validation mode can be specified using the jakarta.persistence.validation.mode map key, which will override the value specified (or defaulted) in the persistence.xml file. The map values for this key are "auto", "callback", "none".

If the auto validation mode is specified by the validation-mode element or the jakarta.persistence.validation.mode property, or if neither the validation-mode element nor the jakarta.persistence.validation.mode property is specified, and a Bean Validation provider is present in the environment, the persistence provider must perform the automatic validation of entities as described in Section 3.7.1.2. If no Bean Validation provider is present in the environment, no lifecycle event validation takes place.

If the callback validation mode is specified by the validation-mode element or the jakarta.persistence.validation.mode property, the persistence provider must perform the lifecycle event validation as described in Section 3.7.1.2. It is an error if there is no Bean Validation provider present in the environment, and the provider must throw the PersistenceException if the jakarta.persistence.validation.mode property value "callback" has been passed to the Persistence.createEntityManagerFactory method.

If the none validation mode is specified by the validation-mode element or the jakarta.persistence.validation.mode property, the persistence provider must not perform lifecycle event validation.

3.7.1.2. Requirements for Automatic Validation upon Lifecycle Events

For each event type, a list of groups is targeted for validation. By default, the default Bean Validation group (the group Default) will be validated upon the pre-persist and pre-update lifecycle validation events, and no group will be validated upon the pre-remove event.

This default validation behavior can be overridden by specifying the target groups using the following validation properties in the persistence.xml file or by passing these properties in the configuration of the entity manager factory through the createEntityManagerFactory method:

  • jakarta.persistence.validation.group.pre-persist

  • jakarta.persistence.validation.group.pre-update

  • jakarta.persistence.validation.group.pre-remove

The value of a validation property must be a list of the targeted groups. A targeted group must be specified by its fully qualified class name. Names must be separated by a comma.

When one of the above events occurs for an entity, the persistence provider must validate that entity by obtaining a Validator instance from the validator factory in use (see Section 3.7.2) and invoking its validate method with the targeted groups. If the list of targeted groups is empty, no validation is performed. If the set of ConstraintViolation objects returned by the validate method is not empty, the persistence provider must throw the jakarta.validation.ConstraintViolationException containing a reference to the returned set of ConstraintViolation objects, and must mark the transaction for rollback if the persistence context is joined to the transaction.

The validator instance that is used for automatic validation upon lifecycle events must use a TraversableResolver that has the following behavior:

  • Attributes that have not been loaded must not be loaded.

  • Validation cascade (@Valid) must not occur for entity associations (single- or multi-valued).

These requirements guarantee that no unloaded attribute or association will be loaded by side effect and that no entity will be validated more than once during a given flush cycle.

Embeddable attributes must be validated only if the Valid annotation has been specified on them.

It is the responsibility of the persistence provider to pass an instance implementing the jakarta.validation.TraversableResolver interface to the Bean Validation provider by calling ValidatorFactory.usingContext().traversableResolver(tr).getValidator() where tr is the resolver having the behavior described above.

3.7.2. Providing the ValidatorFactory

In Jakarta EE environments, a ValidatorFactory instance is made available by the Jakarta EE container. The container is responsible for passing this validator factory to the persistence provider via the map that is passed as an argument to the createContainerEntityManagerFactory call. The map key used by the container must be the standard property name jakarta.persistence.validation.factory.

In Java SE environments, the application can pass the ValidatorFactory instance via the map that is passed as an argument to the Persistence.createEntityManagerFactory call. The map key used must be the standard property name jakarta.persistence.validation.factory. If no ValidatorFactory instance is provided by the application, and if a Bean Validation provider is present in the classpath, the persistence provider must instantiate the ValidatorFactory using the default bootstrapping approach defined by the Bean Validation specification [5], namely Validation.buildDefaultValidatorFactory().

3.8. Entity Graphs

An entity graph is a template that captures the path and boundaries for an operation or query. It is defined in the form of metadata or an object created by the dynamic EntityGraph API.

Entity graphs are used in the specification of “fetch plans” for query or find operations.

The EntityGraph, AttributeNode, and Subgraph interfaces found in Appendix B are used to dynamically construct entity graphs.

The annotations NamedEntityGraph, NamedAttributeNode, and NamedSubgraph described in Section 10.3 are used to statically define entity graphs. The named-entity-graph XML element and its subelements may be used to override these annotations or to define additional named entity graphs.

The semantics of entity graphs with regard to find and query operations are described in Section 3.8.1.

3.8.1. Use of Entity Graphs in find and query operations

An entity graph can be used with the find method or as a query hint to override or augment FetchType semantics.

The standard properties jakarta.persistence.fetchgraph and jakarta.persistence.loadgraph are used to specify such graphs to queries and find operations.

The default fetch graph for an entity or embeddable is defined to consist of the transitive closure of all of its attributes that are specified as FetchType.EAGER (or defaulted as such).

The persistence provider is permitted to fetch additional entity state beyond that specified by a fetch graph or load graph. It is required, however, that the persistence provider fetch all state specified by the fetch or load graph.

3.8.1.1. Fetch Graph Semantics

When the jakarta.persistence.fetchgraph property is used to specify an entity graph, attributes that are specified by attribute nodes of the entity graph are treated as FetchType.EAGER and attributes that are not specified are treated as FetchType.LAZY.

The following rules apply, depending on attribute type. The rules of this section are applied recursively.

A primary key or version attribute never needs to be specified in an attribute node of a fetch graph. (This applies to composite primary keys as well, including embedded id primary keys.) When an entity is fetched, its primary key and version attributes are always fetched. It is not incorrect, however, to specify primary key attributes or version attributes.

Attributes other than primary key and version attributes are assumed not to be fetched unless the attribute is specified. The following rules apply to the specification of attributes.

  • If the attribute is an embedded attribute, and the attribute is specified in an attribute node, but a subgraph is not specified for the attribute, the default fetch graph for the embeddable is fetched. If a subgraph is specified for the attribute, the attributes of the embeddable are fetched according to their specification in the corresponding subgraph.

  • If the attribute is an element collection of basic type, and the attribute is specified in an attribute node, the element collection together with its basic elements is fetched.

  • If the attribute is an element collection of embeddables, and the attribute is specified in an attribute node, but a subgraph is not specified for the attribute, the element collection together with the default fetch graph of its embeddable elements is fetched. If a subgraph is specified for the attribute, the attributes of the embeddable elements are fetched according to the corresponding subgraph specification.

  • If the attribute is a one-to-one or many-to-one relationship, and the attribute is specified in an attribute node, but a subgraph is not specified for the attribute, the default fetch graph of the target entity is fetched. If a subgraph is specified for the attribute, the attributes of the target entity are fetched according to the corresponding subgraph specification.

  • If the attribute is a one-to-many or many-to-many relationship, and the attribute is specified in an attribute node, but a subgraph is not specified, the collection is fetched and the default fetch graphs of the referenced entities are fetched. If a subgraph is specified for the attribute, the entities in the collection are fetched according to the corresponding subgraph specification.

  • If the key of a map which has been specified in an attribute node is a basic type, it is fetched. If the key of a map which has been specified in an attribute node is an embedded type, the default fetch graph is fetched for the embeddable. Otherwise, if the key of the map is an entity, and a map key subgraph is not specified for the attribute node, the map key is fetched according to its default fetch graph. If a key subgraph is specified for the map key attribute, the map key attribute is fetched according to the map key subgraph specification.

Examples:

@NamedEntityGraph
@Entity
public class Phonenumber {
    @Id
    protected String number;

    protected PhoneTypeEnum type;

    // ...
}

In the above example, only the number attribute would be eagerly fetched.

@NamedEntityGraph(
    attributeNodes={@NamedAttributeNode("projects")}
)
@Entity
public class Employee {
    @Id
    @GeneratedValue
    protected long id;

    @Basic
    protected String name;

    @Basic
    protected String employeeNumber;

    @OneToMany()
    protected List<Dependents> dependents;

    @OneToMany()
    protected List<Project> projects;

    @OneToMany()
    protected List<PhoneNumber> phoneNumbers;

    // ...
}

@Entity
@Inheritance
public class Project {
    @Id
    @GeneratedValue
    protected long id;

    String name;

    @OneToOne(fetch=FetchType.EAGER)
    protected Requirements doc;

    // ...
}

@Entity
public class LargeProject extends Project {
    @OneToOne(fetch=FetchType.LAZY)
    protected Employee approver;

    // ...
}

@Entity
public class Requirements {
    @Id
    protected long id;

    @Lob
    protected String description;

    @OneToOne(fetch=FetchType.LAZY)
    protected Approval approval

    // ...
}

In the above example, the Employee entity’s primary key will be fetched as well as the related Project instances, whose default fetch graph (id, name, and doc attributes) will be fetched. The related Requirements object will be fetched according to its default fetch graph.

If the approver attribute of LargeProject were FetchType.EAGER, and if any of the projects were instances of LargeProject, their approver attributes would also be fetched. Since the type of the approver attribute is Employee, the approver’s default fetch graph (id, name, and employeeNumber attributes) would also be fetched.

3.8.1.2. Load Graph Semantics

When the jakarta.persistence.loadgraph property is used to specify an entity graph, attributes that are specified by attribute nodes of the entity graph are treated as FetchType.EAGER and attributes that are not specified are treated according to their specified or default FetchType.

The following rules apply. The rules of this section are applied recursively.

  • A primary key or version attribute never needs to be specified in an attribute node of a load graph. (This applies to composite primary keys as well, including embedded id primary keys.) When an entity is fetched, its primary key and version attributes are always fetched. It is not incorrect, however, to specify primary key attributes or version attributes.

  • If the attribute is an embedded attribute, and the attribute is specified in an attribute node, but a subgraph is not specified for the attribute, the default fetch graph for the embeddable is fetched. If a subgraph is specified for the attribute, attributes that are specified by the subgraph are also fetched.

  • If the attribute is an element collection of basic type, and the attribute is specified in an attribute node, the element collection together with its basic elements is fetched.

  • If the attribute is an element collection of embeddables, and the attribute is specified in an attribute node, the element collection together with the default fetch graph of its embeddable elements is fetched. If a subgraph is specified for the attribute, attributes that are specified by the subgraph are also fetched.

  • If the attribute is a one-to-one or many-to-one relationship, and the attribute is specified in an attribute node, the default fetch graph of the target entity is fetched. If a subgraph is specified for the attribute, attributes that are specified by the subgraph are also fetched.

  • If the attribute is a one-to-many or many-to-many relationship, and the attribute is specified in an attribute node, the collection is fetched and the default fetch graphs of the referenced entities are fetched. If a subgraph is specified for the attribute, attributes that are specified by the subgraph are also fetched.

  • If the key of a map which has been specified in an attribute node is a basic type, it is fetched. If the key of a map which has been specified in an attribute node is an embedded type, the default fetch graph is fetched for the embeddable. Otherwise, if the key of the map is an entity, the map key is fetched according to its default fetch graph. If a key subgraph is specified for the map key attribute, additional attributes are fetched as specified in the key subgraph.

Examples:

@NamedEntityGraph
@Entity
public class Phonenumber {
    @Id
    protected String number;

    protected PhoneTypeEnum type;

    // ...
}

In the above example, the number and type attributes are fetched.

@NamedEntityGraph(
    attributeNodes={@NamedAttributeNode("projects")}
)
@Entity
public class Employee {
    @Id
    @GeneratedValue
    protected long id;

    @Basic
    protected String name;

    @Basic
    protected String employeeNumber;

    @OneToMany()
    protected List<Dependents> dependents;

    @OneToMany()
    protected List<Project> projects;

    @OneToMany()
    protected List<PhoneNumber> phoneNumbers;

    // ...
}

@Entity
@Inheritance
public class Project {
    @Id
    @GeneratedValue
    protected long id;

    String name;

    @OneToOne(fetch=FetchType.EAGER)
    protected Requirements doc;

    // ...
}

@Entity
public class LargeProject extends Project {
    @OneToOne(fetch=FetchType.LAZY)
    protected Employee approver;

    // ...
}

@Entity
public class Requirements {
    @Id
    protected long id;

    @Lob
    protected String description;

    @OneToOne(fetch=FetchType.LAZY)
    protected Approval approval

    // ...
}

In the above example, the default fetch graph (id, name, employeeNumber attributes) of Employee is fetched. The default fetch graphs of the related Project instances (id, name, and doc attributes) and their Requirements instances (id and description attributes) are also fetched.

3.9. Type Conversion of Basic Attributes

The attribute conversion facility allows the developer to define custom attribute converters. A converter is a class whose methods convert between:

  • the target type of the converter, an arbitrary Java type which may be used as the type of a persistent field or property, and

  • a basic type (see Section 2.6) used as an intermediate step in mapping to the database representation.

A converter can be used to convert attributes defined by entity classes, mapped superclasses, or embeddable classes.[54] A converted attribute is considered a basic attribute, since, with the aid of the converter, its values can be represented as instances of a basic type.

Every attribute converter class must implement the interface jakarta.persistence.AttributeConverter and must be annotated with the Converter annotation or declared as a converter in the XML descriptor. If the value of the autoApply element of the Converter annotation is true, the converter is automatically applied to all attributes of the target type, including to basic attribute values that are contained within other, more complex attribute types. See Section 10.6.

/**
 * Interface implemented by custom attribute <em>converters</em>. A
 * converter is a class whose methods convert between:
 * <ul>
 * <li>the <em>target type</em> of the converter, an arbitrary Java
 *     type which may be used as the type of a persistent field or
 *     property, and
 * <li>a {@linkplain Basic basic type} used as an intermediate step
 *     in mapping to the database representation.
 * </ul>
 *
 * <p>A converted field or property is considered {@link Basic}, since,
 * with the aid of the converter, its values can be represented as
 * instances of a basic type.
 *
 * <p>A converter class must be annotated {@link Converter} or declared
 * as a converter in the object/relational mapping descriptor. The value
 * of {@link Converter#autoApply autoApply} determines if the converter
 * is automatically applied to persistent fields and properties of the
 * target type. The {@link Convert} annotation may be used to apply a
 * converter which is declared {@code autoApply=false}, to explicitly
 * {@linkplain Convert#disableConversion disable conversion}, or to
 * resolve ambiguities when multiple converters would otherwise apply.
 *
 * <p>Note that the target type {@code X} and the converted basic type
 * {@code Y} may be the same Java type.
 *
 * @param <X> the target type, that is, the type of the entity attribute
 * @param <Y> a basic type representing the type of the database column
 *
 * @see Converter
 * @see Convert#converter
 */
public interface AttributeConverter<X,Y> {

    /**
     * Converts the value stored in the entity attribute into the 
     * data representation to be stored in the database.
     *
     * @param attribute  the entity attribute value to be converted
     * @return  the converted data to be stored in the database column
     */
    Y convertToDatabaseColumn(X attribute);

    /**
     * Converts the data stored in the database column into the value
     * to be stored in the entity attribute.
     *
     * <p>Note that it is the responsibility of the converter writer
     * to specify the correct {@code dbData} type for the corresponding
     * column for use by the JDBC driver: i.e., persistence providers
     * are not expected to do such type conversion.
     *
     * @param dbData  the data from the database column to be converted
     * @return  the converted value to be stored in the entity attribute
     */
    X convertToEntityAttribute(Y dbData);
}

Attribute converter classes in Jakarta EE environments support dependency injection through the Contexts and Dependency Injection API (CDI) [7] when CDI is enabled[55]. An attribute converter class that makes use of CDI injection may also define lifecycle callback methods annotated with the PostConstruct and PreDestroy annotations. These methods will be invoked after injection has taken place and before the attribute converter instance is destroyed respectively.

The persistence provider is responsible for using the CDI SPI to create instances of the attribute converter class; to perform injection upon such instances; to invoke their PostConstruct and PreDestroy methods, if any; and to dispose of the attribute converter instances.

The persistence provider is only required to support CDI injection into attribute converters in Jakarta EE container environments[56]. If CDI is not enabled, the persistence provider must not invoke attribute converters that depend upon CDI injection.

An attribute converter is a noncontextual object. In supporting injection into attribute converters, the persistence provider must behave as if it carries out the following steps involving the use of the CDI SPI. (See [7]).

  • Obtain a BeanManager instance. (See Section 9.1.)

  • Create an AnnotatedType instance for the attribute converter class.

  • Create an InjectionTarget instance for the annotated type.

  • Create a CreationalContext.

  • Instantiate the listener by calling the InjectionTarget produce method.

  • Inject the listener instance by calling the InjectionTarget inject method on the instance.

  • Invoke the PostConstruct callback, if any, by calling the InjectionTarget postConstruct method on the instance.

When the listener instance is to be destroyed, the persistence provider must behave as if it carries out the following steps.

  • Call the InjectionTarget preDestroy method on the instance.

  • Call the InjectionTarget dispose method on the instance.

  • Call the CreationalContext release method.

Persistence providers may optimize the steps above, e.g. by avoiding calls to the actual CDI SPI and relying on container-specific interfaces instead, as long as the outcome is the same.

Attribute converters that do not make use of CDI injection are stateless. The lifecycle of such attribute converters is unspecified.

The conversion of all basic types is supported except for the following: Id attributes (including the attributes of embedded ids and derived identities), version attributes, relationship attributes, and attributes explicitly annotated as Enumerated or Temporal or designated as such in the XML descriptor. Auto-apply converters will not be applied to such attributes, and applications that apply converters to such attributes through use of the Convert annotation will not be portable.

Type conversion may be specified at the level of individual attributes by means of the Convert annotation. The Convert annotation may also be used to override or disable an auto-apply conversion. See Section 11.1.10.

The Convert annotation may be applied directly to an attribute of an entity, mapped superclass, or embeddable class to specify conversion of the attribute or to override the use of a converter that has been specified as autoApply=true. When persistent properties are used, the Convert annotation is applied to the getter method.

The Convert annotation may be applied to an entity that extends a mapped superclass to specify or override the conversion mapping for an inherited basic or embedded attribute.

The persistence provider runtime is responsible for invoking the specified conversion methods for the target attribute type when loading the entity attribute from the database and before storing the entity attribute state to the database. The persistence provider must apply any conversion methods to instances of attribute values in path expressions used within Jakarta Persistence query language queries or criteria queries (such as in comparisons, bulk updates, etc.) before sending them to the database for the query execution. When such converted attributes are used in comparison operations with literals or parameters, the value of the literal or parameter to which they are compared must also be converted. If the result of a Jakarta Persistence query language query or criteria query includes one or more entity attributes for which conversion mappings have been specified, the persistence provider must apply the specified conversions to the corresponding values in the query result before returning them to the application. The use of functions, including aggregates, on converted attributes is undefined. If an exception is thrown from a conversion method, the persistence provider must wrap the exception in a PersistenceException and, if the persistence context is joined to a transaction, mark the transaction for rollback.

3.10. Second-Level Cache

A persistence provider may support the use of a second-level cache, that is, it might have a way to store data read in one persistence context for use in subsequent persistence contexts. A second-level cache might enhance performance, but tends to undermine the semantics of transaction processing, possibly exposing the application to stale data or similar anomalies.

Access to the second-level cache, if enabled, is mediated via the persistence context, and is largely transparent to the application. As an exception, the Cache interface described below in Section 3.10.3 allows the application to directly evict data from the second-level cache.

The persistence provider is not required to support use of a second-level cache.

3.10.1. The Shared Cache Mode and Cacheable Annotation

Whether a given entity is eligible for storage in the second level cache is determined by:

  • the annotations of the entity class, and

  • the value specified for the shared-cache-mode element of the persistence.xml file or by the configuration property jakarta.persistence.sharedCache.mode.

The value of the property jakarta.persistence.sharedCache.mode takes precedence over the value of the shared-cache-mode element.

The shared-cache-mode element takes one of five possible values, which are enumerated by jakarta.persistence.SharedCacheMode:

  • ALL specifies that every entity and all its state may be cached.

  • NONE specifies that caching is disabled for the persistence unit, and that the persistence provider must not cache any entity data.

  • ENABLE_SELECTIVE specifies that an entity may be cached if the entity class is explicitly annotated @Cacheable or @Cacheable(true), or if the equivalent setting is specified in XML.

  • DISABLE_SELECTIVE specifies that an entity may be cached unless the entity class is explicitly annotated @Cacheable(false), or unless the equivalent setting is specified in XML.

  • UNSPECIFIED selects the provider-specific default behavior.

If neither the shared-cache-mode element nor the property jakarta.persistence.sharedCache.mode is specified, or if the specified value is UNSPECIFIED, the behavior is not defined, and provider-specific defaults may apply. In particular, the semantics of the Cacheable annotation (and XML equivalent) is undefined.

If the persistence provider does not support use of a second-level cache, or if a second-level cache is not installed or not enabled, this setting may be ignored and no caching will occur.

A persistence provider may support additional vendor-specific mechanisms for configuring the cache and marking entities eligible (or not) for storage in the second-level cache. However, if a second-level cache is supported, and enabled, the provider must respect the configuration options defined in this section, if specified by the application.

3.10.2. Cache Modes

The cache retrieve mode and cache store mode control how a given persistence context by interacts with the second-level cache.

  • The cache retrieve mode may be set by calling setCacheRetrieveMode() on EntityManager or Query.

  • The cache store mode may be set by calling setCacheStoreMode() on EntityManager or Query.

  • A cache store mode or cache retrieve mode, or both, may be passed to the find() method of EntityManager as a FindOption.

  • A cache store mode may be passed to the refresh() method of EntityManager as a RefreshOption.

A cache mode specified for a given Query instance applies only to executions of that query, but takes precedence over the current cache mode of the EntityManager to which the Query belongs. A cache mode passed to find() or refresh() applies only to the method invocation, and takes precedence over the current cache mode of the EntityManager.

Alternatively, a cache mode may be specified using the property name jakarta.persistence.cache.retrieveMode or jakarta.persistence.cache.storeMode by:

  • calling the setProperty() method of EntityManager,

  • calling the setHint() method of Query, or

  • passing a map containing one of these properties to find() or refresh().

If second-level caching is not enabled (for example, if the shared-cache-mode element is set to NONE), cache modes must be ignored. Similarly, if a given entity is not eligible for storage in the second-level cache (for example, if the shared-cache-mode element is set to ENABLE_SELECTIVE, and the entity is not annotated @Cacheable), cache modes are ignored for operations applying to that entity.

Cache modes must be respected when caching is enabled, regardless of whether caching is enabled via the configuration options defined by this specification or via provider-specific mechanisms.

Applications which depend on the cache retrieve mode or cache store mode but which do not specify the shared-cache-mode element are not portable.

CacheRetrieveMode enumerates the cache retrieve modes recognized by this specification. The semantics of each mode is defined by its Javadoc.

/**
 * Specifies how the {@link EntityManager} interacts with the
 * second-level cache when data is read from the database via
 * the {@link EntityManager#find} methods and execution of
 * queries.
 * <ul>
 * <li>{@link #USE} indicates that data may be read from the
 *     second-level cache.
 * <li>{@link #BYPASS} indicates that data may not be read
 *     from the second-level cache.
 * </ul>
 *
 * <p>Enumerates legal values of the property
 * {@code jakarta.persistence.cache.retrieveMode}.
 *
 * @see EntityManager#setCacheRetrieveMode(CacheRetrieveMode)
 * @see Query#setCacheRetrieveMode(CacheRetrieveMode)
 *
 * @since 2.0
 */
public enum CacheRetrieveMode implements FindOption {

    /**
     * Read entity data from the cache: this is the default
     * behavior.
     */
    USE,

    /**
     * Bypass the cache: get data directly from the database.
     */
    BYPASS  
}

CacheStoreMode enumerates the cache store modes recognized by this specification. The semantics of each mode is defined by its Javadoc.

/**
 * Specifies how the {@link EntityManager} interacts with the
 * second-level cache when data is read from the database and
 * when data is written to the database.
 * <ul>
 * <li>{@link #USE} indicates that data may be written to the
 *     second-level cache.
 * <li>{@link #BYPASS} indicates that data may not be written
 *     to the second-level cache.
 * <li>{@link #REFRESH} indicates that data must be written
 *     to the second-level cache, even when the data is already
 *     cached.
 * </ul>
 *
 * <p>Enumerates legal values of the property
 * {@code jakarta.persistence.cache.storeMode}.
 *
 * @see EntityManager#setCacheStoreMode(CacheStoreMode)
 * @see Query#setCacheStoreMode(CacheStoreMode)
 *
 * @since 2.0
 */
public enum CacheStoreMode implements FindOption, RefreshOption {

    /**
     * Insert entity data into cache when read from database and
     * insert/update entity data when written to the database:
     * this is the default behavior. Does not force refresh of
     * already cached items when reading from database.
     */
    USE,

    /**
     * Don't insert into cache. 
     */
    BYPASS,

    /**
     * Insert/update entity data held in the cache when read from
     * the database and when written to the database. Force refresh
     * of cache for items read from database.
     */
    REFRESH
}

3.10.3. Cache Interface

The Cache interface found in Section B.5 allows the application to request eviction of entity data from the second-level cache directly and immediately, outside the scope of any persistence context.

3.11. Query APIs

The Query and TypedQuery APIs are used for the execution of both static queries and dynamic queries. These APIs also support parameter binding and pagination control. The StoredProcedureQuery API is used for the execution of queries that invoke stored procedures defined in the database.

These interfaces may be found in Appendix B.

3.11.1. Query Execution

Jakarta Persistence query language, Criteria API, and native SQL select queries are executed using the methods getResultList, getSingleResult, and getSingleResultOrNull. Update and delete operations (update and delete “queries”) are executed using the executeUpdate method.

  • For TypedQuery instances, the query result type is determined in the case of criteria queries by the type of the query specified when the CriteriaQuery object is created, as described in Section 6.3.1. In the case of Jakarta Persistence query language queries, the type of the result is determined by the resultClass argument to the createQuery or createNamedQuery method, and the select list of the query must contain only a single item which must be assignable to the specified type.

  • For Query instances, the elements of a query result whose select list consists of more than one select expression are of type Object[]. If the select list consists of only one select expression, the elements of the query result are of type Object. When native SQL queries are used, the SQL result set mapping (see Section 3.11.11), determines how many items (entities, scalar values, etc.) are returned. If multiple items are returned, the elements of the query result are of type Object[]. If only a single item is returned as a result of the SQL result set mapping or if a result class is specified, the elements of the query result are of type Object.

The semantics of the methods

public <T> TypedQuery<T> createQuery(String qlString, Class<T> resultClass)
public <T> TypedQuery<T> createNamedQuery(String name, Class<T> resultClass)

may be extended in a future release of this specification to support other result types. Use of other result types, including Tuple.class, is not portable.

Stored procedure queries can be executed using the getResultList, getSingleResult, getSingleResultOrNull, and execute methods. Stored procedures that perform only updates or deletes can be executed using the executeUpdate method. Stored procedure query execution is described in detail in Section 3.11.12.3.

An IllegalArgumentException is thrown if a parameter instance is specified that does not correspond to a parameter of the query, if a parameter name is specified that does not correspond to a named parameter of the query, if a positional value is specified that does not correspond to a positional parameter of the query, or if the type of the parameter is not valid for the query. This exception may be thrown when the parameter is bound, or the execution of the query may fail. See Section 3.11.5, Section 3.11.6, and Section 3.11.7 for supported parameter usage.

The effect of applying setMaxResults or setFirstResult to a query involving fetch joins over collections is undefined. The use of setMaxResults and setFirstResult is not supported for stored procedure queries.

Query and TypedQuery methods other than the executeUpdate method are not required to be invoked within a transaction context, unless a lock mode other than LockModeType.NONE has been specified for the query. In particular, the getResultList, getSingleResult, and getSingleResultOrNull methods are not required to be invoked within a transaction context unless such a lock mode has been specified for the query[57]. If an entity manager with transaction-scoped persistence context is in use, the resulting entities will be detached; if an entity manager with an extended persistence context is used, they will be managed. See Chapter 7 for further discussion of entity manager use outside a transaction and persistence context types.

Whether a StoredProcedureQuery should be invoked in a transaction context should be determined by the transactional semantics and/or requirements of the stored procedure implementation and the database in use. In particular, problems may occur if the stored procedure initiates a transaction and a transaction is already in effect. The state of any entities returned by the stored procedure query invocation is determined as decribed above.

Runtime exceptions other than the NoResultException, NonUniqueResultException, QueryTimeoutException, and LockTimeoutException thrown by the methods of the Query, TypedQuery, and StoredProcedureQuery interfaces other than those methods specified below cause the current transaction to be marked for rollback if the persistence context is joined to the transaction. On database platforms on which a query timeout causes transaction rollback, the persistence provider must throw the PersistenceException instead of the QueryTimeoutException.

Runtime exceptions thrown by the following methods of the Query, TypedQuery, and StoredProcedureQuery interfaces do not cause the current transaction to be marked for rollback: getParameters, getParameter, getParameterValue, getOutputParameterValue, getLockMode.

Runtime exceptions thrown by the methods of the Tuple, TupleElement, and Parameter interfaces do not cause the current transaction to be marked for rollback.

For example:

public List findWithName(String name) {
    return em.createQuery("SELECT c FROM Customer c WHERE c.name LIKE :custName")
        .setParameter("custName", name)
        .setMaxResults(10)
        .getResultList();
}

3.11.2. Queries and Flush Mode

The flush mode setting affects the result of a query as follows.

When queries are executed within a transaction, if FlushModeType.AUTO is set on the Query, TypedQuery, or StoredProcedureQuery object, or if the flush mode setting for the persistence context is AUTO (the default) and a flush mode setting has not been specified for the query object, the persistence provider is responsible for ensuring that all updates to the state of all entities in the persistence context which could potentially affect the result of the query are visible to the processing of the query. The persistence provider implementation may achieve this by flushing those entities to the database or by some other means. If FlushModeType.COMMIT is set, the effect of updates made to entities in the persistence context upon queries is unspecified.

If the persistence context has not been joined to the current transaction, the persistence provider must not flush to the database regardless of the flush mode setting.

/**
 * Enumerates flush modes recognized by the {@link EntityManager}.
 *
 * <p>When queries are executed within a transaction, if {@link #AUTO}
 * is set on the {@link Query Query} or {@link TypedQuery} object, or
 * if the flush mode setting for the persistence context is {@code AUTO}
 * (the default) and a flush mode setting has not been specified for the
 * {@code Query} or {@code TypedQuery} object, the persistence provider
 * is responsible for ensuring that all updates to the state of all
 * entities in the persistence context which could potentially affect
 * the result of the query are visible to the processing of the query.
 * The persistence provider implementation may achieve this by flushing
 * updates to those entities to the database or by some other means.
 *
 * <p>On the other hand, if {@link #COMMIT} is set, the effect of updates
 * made to entities in the persistence context on queries is unspecified.
 *
 * <p>If there is no transaction active or the persistence context is
 * not joined to the current transaction, the persistence provider must
 * not flush to the database.
 *
 * @see EntityManager#setFlushMode(FlushModeType)
 * @see Query#setFlushMode(FlushModeType)
 *
 * @since 1.0
 */
public enum FlushModeType {

    /**
     * Flushing to occur at transaction commit. The provider may flush
     * at other times, but is not required to.
     */
   COMMIT,

    /**
     * (Default) Flushing to occur at query execution.
     */
   AUTO
}

If there is no transaction active, the persistence provider must not flush to the database.

3.11.3. Queries and Lock Mode

The setLockMode method of the Query or TypedQuery interface or the lockMode element of the NamedQuery annotation may be used to lock the results of a query. A lock is obtained for each entity specified in the query result (including entities passed to constructors in the query SELECT clause).[58]

If the lock mode type is PESSIMISTIC_READ, PESSIMISTIC_WRITE, or PESSIMISTIC_FORCE_INCREMENT, and the query returns scalar data (e.g., the values of entity field or properties, including scalar data passed to constructors in the query SELECT clause), the underlying database rows will be locked[59], but the version columns (if any) for any entities corresponding to such scalar data will not be updated unless the entities themselves are also otherwise retrieved and updated.

If the lock mode type is OPTIMISTIC or OPTIMISTIC_FORCE_INCREMENT, and the query returns scalar data, any entities returned by the query will be locked, but no locking will occur for scalar data that does not correspond to the state of any entity instance in the query result.

If a lock mode other than NONE is specified for a query, the query must be executed within a transaction (and the persistence context must be joined to the transaction) or the TransactionRequiredException will be thrown.

Locking is supported for Jakarta Persistence query language queries and criteria queries only. If the setLockMode or getLockMode method is invoked on a query that is not a Jakarta Persistence query language select query or a criteria query, the IllegalStateException may be thrown or the query execution will fail.

3.11.4. Query Hints

The following hint is defined by this specification for use in query configuration.

jakarta.persistence.query.timeout // time in milliseconds

This hint may:

  • be passed to the setHint() method of the Query, TypedQuery, and StoredProcedureQuery interfaces found in Appendix B,

  • used with the NamedQuery, NamedNativeQuery, and NamedStoredProcedureQuery annotations specified in Section 10.4,

  • passed as a property to the createEntityManagerFactory() method of the Persistence class, as defined in Section 9.7, or

  • used in the properties element of the persistence.xml file, as defined in Section 8.2.1.11.

The timeout specified by calling the createEntityManagerFactory() method, via the persistence.xml file, or in annotations, serves as a default value which can be selectively overridden by calling the setHint() method.

Portable applications should not rely on this hint. Depending on the persistence provider and database in use, the hint may or may not be observed.

Vendors are permitted to support the use of additional, vendor-specific hints. Vendor-specific hints must not use the jakarta.persistence namespace. Vendor-specific hints must be ignored if they are not understood.

3.11.5. Parameter Objects

Parameter objects can be used for criteria queries and for Jakarta Persistence query language queries.

Implementations may support the use of Parameter objects for native queries, however support for Parameter objects with native queries is not required by this specification. The use of Parameter objects for native queries will not be portable. The mixing of parameter objects with named or positional parameters is invalid.

Portable applications should not attempt to reuse a Parameter object obtained from a Query or TypedQuery instance in the context of a different Query or TypedQuery instance.

3.11.6. Named Parameters

Named parameters can be used for Jakarta Persistence query language queries, for criteria queries (although use of Parameter objects is to be preferred), and for stored procedure queries that support named parameters.

Named parameters follow the rules for identifiers defined in Section 4.4.1. Named parameters are case-sensitive. The mixing of named and positional parameters is invalid.

A named parameter of a Jakarta Persistence query language query is an identifier that is prefixed by the " : " symbol. The parameter names passed to the setParameter methods of the Query and TypedQuery interfaces do not include this " : " prefix.

3.11.7. Positional Parameters

Only positional parameter binding and positional access to result items may be portably used for native queries, except for stored procedure queries for which named parameters have been defined. When binding the values of positional parameters, the numbering starts as “ 1 ”. It is assumed that for native queries the parameters themselves use the SQL syntax (i.e., “ ? ”, rather than “ ?1 ”).

The use of positional parameters is not supported for criteria queries.

3.11.8. Arguments to query parameters

Arguments are assigned to query parameters by calling Query.setParameter(). The first parameter of setParameter() identifies the named or positional parameter of the query.

An argument may be assigned to a single-valued parameter of a JPQL or native SQL query by passing the argument to the second parameter of setParameter().

query.setParameter("name", name)

A list of arguments may be assigned to a collection-valued parameter of a JPQL query by packaging the arguments in a non-null instance of java.util.List and passing the list as an argument to the second parameter of setParameter(). The list should contain at least one element. If the list is empty the behavior is undefined. Portable applications should not pass an empty list to a collection-valued parameter.

query.setParameter("names", List.of(name1, name2, name3))

3.11.9. Named Queries

Named queries are static queries expressed in metadata or queries registered by means of the EntityManagerFactory addNamedQuery method. Named queries can be defined in the Jakarta Persistence query language or in SQL. Query names are scoped to the persistence unit.

The following is an example of the definition of a named query defined in metadata:

@NamedQuery(
    name="findAllCustomersWithName",
    query="SELECT c FROM Customer c WHERE c.name LIKE :custName"
)

The following is an example of the use of a named query:

@PersistenceContext
public EntityManager em;
    // ...

    customers = em.createNamedQuery("findAllCustomersWithName")
        .setParameter("custName", "Smith")
        .getResultList();

3.11.10. Polymorphic Queries

By default, all queries are polymorphic. That is, the FROM clause of a query designates not only instances of the specific entity class(es) to which it explicitly refers, but subclasses as well. The instances returned by a query include instances of the subclasses that satisfy the query conditions.

For example, the following query returns the average salary of all employees, including subtypes of Employee, such as Manager and Exempt.

select avg(e.salary) from Employee e where e.salary > 80000

Entity type expressions, described in Section 4.7.12, as well as the use of downcasting, described in Section 4.4.9, can be used to restrict query polymorphism.

3.11.11. SQL Queries

Queries may be expressed in native SQL. The result of a native SQL query may consist of entities, unmanaged instances created via constructors, scalar values, or some combination of these.

The SQL query facility is intended to provide support for those cases where it is necessary to use the native SQL of the target database in use (and/or where the Jakarta Persistence query language cannot be used). Native SQL queries are not expected to be portable across databases.

3.11.11.1. Returning Managed Entities from Native Queries

The persistence provider is responsible for performing the mapping between the values returned by the SQL query and entity attributes in accordance with the object/relational mapping metadata for the entity or entities. In particular, the names of the columns in the SQL result are used to map to the entity attributes as defined by this metadata. This mapping includes the mapping of the attributes of any embeddable classes that are part of the non-collection-valued entity state and attributes corresponding to foreign keys contained as part of the entity state[60].

When an entity is to be returned from a native query, the SQL statement should select all of the columns that are mapped to the entity object. This should include foreign key columns to related entities. The results obtained when insufficient data is available are undefined.

In the simplest case—i.e., when the results of the query are limited to entities of a single entity class and the mapping information can be derived from the columns of the SQL result and the object/relational mapping metadata—it is sufficient to specify only the expected class of the entity result.

The following example illustrates the case where a native SQL query is created dynamically using the createNativeQuery method and the entity class that specifies the type of the result is passed in as an argument.

Query q = em.createNativeQuery(
    "SELECT o.id, o.quantity, o.item " +
        "FROM Order o, Item i " +
        "WHERE (o.item = i.id) AND (i.name = 'widget')",
    com.acme.Order.class);

When executed, this query will return a collection of all Order entities for items named “widget”.

The SqlResultSetMapping metadata annotation—which is designed to handle more complex cases—can be used as an alternative here. See Section 10.4.4 for the definition of the SqlResultSetMapping metadata annotation and related annotations.

For the query shown above, the SqlResultSetMapping metadata for the query result type might be specified as follows:

@SqlResultSetMapping(
    name="WidgetOrderResults",
    entities=@EntityResult(entityClass=com.acme.Order.class))

The same results as produced by the query above can then obtained by the following:

Query q = em.createNativeQuery(
    "SELECT o.id, o.quantity, o.item " +
        "FROM Order o, Item i " +
        "WHERE (o.item = i.id) AND (i.name = 'widget')",
    "WidgetOrderResults");

When multiple entities are returned by a SQL query or when the column names of the SQL result do not correspond to those of the object/relational mapping metadata, a SqlResultSetMapping metadata definition must be provided to specify the entity mapping.

The following query and SqlResultSetMapping metadata illustrates the return of multiple entity types. It assumes default metadata and column name defaults.

Query q = em.createNativeQuery(
    "SELECT o.id, o.quantity, o.item, i.id, i.name, i.description " +
        "FROM Order o, Item i " +
        "WHERE (o.quantity > 25) AND (o.item = i.id)",
    "OrderItemResults");

@SqlResultSetMapping(name="OrderItemResults", entities={
    @EntityResult(entityClass=com.acme.Order.class),
    @EntityResult(entityClass=com.acme.Item.class)
})

When the column names of the SQL result do not correspond to those of the object/relational mapping metadata or introduce a conflict in mapping column defaults as in the example code above, more explicit SQL result mapping metadata must be provided to enable the persistence provider runtime to map the JDBC results into the expected objects. This might arise, for example, when column aliases must be used in the SQL SELECT clause when the SQL result would otherwise contain multiple columns of the same name or when columns in the SQL result are the results of operators or functions. The FieldResult annotation element within the EntityResult annotation is used to specify the mapping of such columns to entity attributes.

The following example combining multiple entity types includes aliases in the SQL statement. This requires that the column names be explicitly mapped to the entity fields corresponding to those columns. The FieldResult annotation is used for this purpose.

Query q = em.createNativeQuery(
    "SELECT o.id AS order_id, " +
        "o.quantity AS order_quantity, " +
        "o.item AS order_item, " +
        "i.id, i.name, i.description " +
        "FROM Order o, Item i " +
        "WHERE (order_quantity > 25) AND (order_item = i.id)",
    "OrderItemResults");

@SqlResultSetMapping(name="OrderItemResults", entities={
    @EntityResult(entityClass=com.acme.Order.class, fields={
        @FieldResult(name="id", column="order_id"),
        @FieldResult(name="quantity", column="order_quantity"),
        @FieldResult(name="item", column="order_item")}),
    @EntityResult(entityClass=com.acme.Item.class)
})

When the returned entity type contains an embeddable class, the FieldResult element must use a dot (“ . ”) notation to indicate which column maps to which field or property of the contained embeddable.

Example:

Query q = em.createNativeQuery(
    "SELECT c.id AS customer_id, " +
        "c.street AS customer_street, " +
        "c.city AS customer_city, " +
        "c.state AS customer_state, " +
        "c.status AS customer_status " +
        "FROM Customer c " +
        "WHERE c.status = 'GOLD' ",
    "CustomerResults");

@SqlResultSetMapping(name=CustomerResults, entities={
    @EntityResult(entityClass=com.acme.Customer.class, fields={
        @FieldResult(name="id", column="customer_id"),
        @FieldResult(name="address.street", column="customer_street"),
        @FieldResult(name="address.city", column="customer_city"),
        @FieldResult(name="address.state", column="customer_state"),
        @FieldResult(name="status", column="customer_status")
    })
})

When the returned entity type is the owner of a single-valued relationship and the foreign key is a composite foreign key (composed of multiple columns), a FieldResult element should be used for each of the foreign key columns. The FieldResult element must use the dot (“ . ”) notation form to indicate the column that maps to each property or field of the target entity primary key.

If the target entity has a primary key of type IdClass, this specification takes the form of the name of the field or property for the relationship, followed by a dot (“ . ”), followed by the name of the field or property of the primary key in the target entity. The latter will be annotated with Id, as specified in Section 11.1.23.

Example:

Query q = em.createNativeQuery(
    "SELECT o.id AS order_id, " +
        "o.quantity AS order_quantity, " +
        "o.item_id AS order_item_id, " +
        "o.item_name AS order_item_name, " +
        "i.id, i.name, i.description " +
        "FROM Order o, Item i " +
        "WHERE (order_quantity > 25) AND (order_item_id = i.id) " +
        "AND (order_item_name = i.name)",
    "OrderItemResults");

@SqlResultSetMapping(name="OrderItemResults", entities={
    @EntityResult(entityClass=com.acme.Order.class, fields={
        @FieldResult(name="id", column="order_id"),
        @FieldResult(name="quantity", column="order_quantity"),
        @FieldResult(name="item.id", column="order_item_id")}),
        @FieldResult(name="item.name", column="order_item_name")}),
    @EntityResult(entityClass=com.acme.Item.class)
})

If the target entity has a primary key of type EmbeddedId, this specification is composed of the name of the field or property for the relationship, followed by a dot (“ . ”), followed by the name or the field or property of the primary key (i.e., the name of the field or property annotated as EmbeddedId), followed by the name of the corresponding field or property of the embedded primary key class.

Example:

Query q = em.createNativeQuery(
    "SELECT o.id AS order_id, " +
        "o.quantity AS order_quantity, " +
        "o.item_id AS order_item_id, " +
        "o.item_name AS order_item_name, " +
        "i.id, i.name, i.description " +
        "FROM Order o, Item i " +
        "WHERE (order_quantity > 25) AND (order_item_id = i.id) AND (order_item_name = i.name)",
    "OrderItemResults");

@SqlResultSetMapping(name="OrderItemResults", entities={
    @EntityResult(entityClass=com.acme.Order.class, fields={
        @FieldResult(name="id", column="order_id"),
        @FieldResult(name="quantity", column="order_quantity"),
        @FieldResult(name="item.itemPk.id", column="order_item_id")}),
        @FieldResult(name="item.itemPk.name", column="order_item_name")}),
    @EntityResult(entityClass=com.acme.Item.class)
})

The FieldResult elements for the composite foreign key are combined to form the primary key EmbeddedId class for the target entity. This may then be used to subsequently retrieve the entity if the relationship is to be eagerly loaded.

The dot-notation form is not required to be supported for any usage other than for embeddables, composite foreign keys, or composite primary keys.

3.11.11.2. Returning Unmanaged Instances

Instances of other classes (including non-managed entity instances) as well as scalar results can be returned by a native query. These can be used singly, or in combination, including with entity results.

Scalar Results

Scalar results can be included in the query result by specifying the ColumnResult annotation element of the SqlResultSetMapping annotation. The intended type of the result can be specified using the type element of the ColumnResult annotation.

Query q = em.createNativeQuery(
    "SELECT o.id AS order_id, " +
        "o.quantity AS order_quantity, " +
        "o.item AS order_item, " +
        "i.name AS item_name, " +
        "i.availabilityDate AS item_shipdate " +
        "FROM Order o, Item i " +
        "WHERE (order_quantity > 25) AND (order_item = i.id)",
    "OrderResults");

@SqlResultSetMapping(
    name="OrderResults",
    entities={
        @EntityResult(entityClass=com.acme.Order.class, fields={
            @FieldResult(name="id", column="order_id"),
            @FieldResult(name="quantity", column="order_quantity"),
            @FieldResult(name="item", column="order_item")}
        )},
    columns={
        @ColumnResult(name="item_name"),
        @ColumnResult(name="item_shipdate", type=java.util.Date.class)
    })
Constructor Results

The mapping to constructors is specified using the ConstructorResult annotation element of the SqlResultSetMapping annotation. The targetClass element of the ConstructorResult annotation specifies the class whose constructor corresponds to the specified columns. All columns corresponding to arguments of the intended constructor must be specified using the columns element of the ConstructorResult annotation in the same order as that of the argument list of the constructor. Any entities returned as constructor results will be in either the new or the detached state, depending on whether a primary key is retrieved for the constructed object.

Example:

Query q = em.createNativeQuery(
    "SELECT c.id, c.name, COUNT(o) as orderCount, AVG(o.price) AS avgOrder " +
        "FROM Customer c, Orders o " +
        "WHERE o.cid = c.id " +
        "GROUP BY c.id, c.name",
    "CustomerDetailsResult");

@SqlResultSetMapping(name="CustomerDetailsResult", classes={
    @ConstructorResult(targetClass=com.acme.CustomerDetails.class, columns={
        @ColumnResult(name="id"),
        @ColumnResult(name="name"),
        @ColumnResult(name="orderCount"),
        @ColumnResult(name="avgOrder", type=Double.class)})
})
3.11.11.3. Combinations of Result Types

When a SqlResultSetMapping specifies more than one mapping type (i.e., more than one of EntityResult, ConstructorResult, ColumnResult), then for each row in the SQL result, the query execution will result in an Object[] instance whose elements are as follows, in order: any entity results (in the order in which they are defined in the entities element); any instances of classes corresponding to constructor results (in the order defined in the classes element); and any instances corresponding to column results (in the order defined in the columns element). If there are any columns whose result mappings have not been specified, they are ignored.

3.11.11.4. Restrictions

When an entity is being returned, the SQL statement should select all of the columns that are mapped to the entity object. This should include foreign key columns to related entities. The results obtained when insufficient data is available are undefined. A SQL result set mapping must not be used to map results to the non-persistent state of an entity.

The use of named parameters is not defined for native SQL queries. Only positional parameter binding for SQL queries may be used by portable applications.

3.11.12. Stored Procedures

The StoredProcedureQuery interface supports the use of database stored procedures.

Stored procedures can be specified either by means of the NamedStoredProcedureQuery annotation or dynamically. Annotations for the specification of stored procedures are described in Section 10.4.3.

3.11.12.1. Named Stored Procedure Queries

Unlike in the case of a named native query, the NamedStoredProcedureQuery annotation names a stored procedure that exists in the database rather than providing a stored procedure definition. The NamedStoredProcedureQuery annotation specifies the types of all parameters to the stored procedure, their corresponding parameter modes (IN, OUT, INOUT, REF_CURSOR[61]), and how result sets, if any, are to be mapped. The name that is assigned to the stored procedure in the NamedStoredProcedureQuery annotation is passed as an argument to the createNamedStoredProcedureQuery method to create an executable StoredProcedureQuery object.

A stored procedure may return more than one result set. As with native queries, the mapping of result sets can be specified either in terms of a resultClasses or as a resultSetMappings annotation element. If there are multiple result sets, it is assumed that they will be mapped using the same mechanism — e.g., all via a set of result class mappings or all via a set of result set mappings. The order of the specification of these mappings must be the same as the order in which the result sets will be returned by the stored procedure invocation. If the stored procedure returns one or more result sets and no resultClasses or resultSetMappings element has been specified, any result set will be returned as a list of type Object[]. The combining of different strategies for the mapping of stored procedure result sets is undefined.

StoredProcedureParameter metadata needs to be provided for all parameters. Parameters must be specified in the order in which they occur in the parameter list of the stored procedure. If parameter names are used, the parameter name is used to bind the parameter value and to extract the output value (if the parameter is an INOUT or OUT parameter). If parameter names are not specified, it is assumed that positional parameters are used. The mixing of named and positional parameters is invalid.

3.11.12.2. Dynamically-specified Stored Procedure Queries

If the stored procedure is not defined using metadata, parameter and result set information must be provided dynamically.

All parameters of a dynamically-specified stored procedure query must be registered using the registerStoredProcedureParameter method of the StoredProcedureQuery interface.

Result set mapping information can be provided by means of the createStoredProcedureQuery method.

3.11.12.3. Stored Procedure Query Execution

Stored procedure query execution can be controlled as described below.

The setParameter methods are used to set the values of all required IN and INOUT parameters. It is not required to set the values of stored procedure parameters for which default values have been defined by the stored procedure.

When getResultList, getSingleResult, and getSingleResultOrNull are called on a StoredProcedureQuery object, the persistence provider will call execute on an unexecuted stored procedure query before processing getResultList, getSingleResult or getSingleResultOrNull.

When executeUpdate is called on a StoredProcedureQuery object, the persistence provider will call execute on an unexecuted stored procedure query followed by getUpdateCount. The results of executeUpdate will be those of getUpdateCount.

The execute method supports both the simple case where scalar results are passed back only via INOUT and OUT parameters as well as the most general case (multiple result sets and/or update counts, possibly also in combination with output parameter values).

The execute method returns true if the first result is a result set, and false if it is an update count or there are no results other than through INOUT and OUT parameters, if any.

If the execute method returns true, the pending result set can be obtained by calling getResultList, getSingleResult, or getSingleResultOrNull. The hasMoreResults method can then be used to test for further results.

If execute or hasMoreResults returns false, the getUpdateCount method can be called to obtain the pending result if it is an update count. The getUpdateCount method will return either the update count (zero or greater) or -1 if there is no update count (i.e., either the next result is a result set or there is no next update count).

For portability, results that correspond to JDBC result sets and update counts need to be processed before the values of any INOUT or OUT parameters are extracted.

After results returned through getResultList and getUpdateCount have been exhausted, results returned through INOUT and OUT parameters can be retrieved.

The getOutputParameterValue methods are used to retrieve the values passed back from the procedure through INOUT and OUT parameters.

When using REF_CURSOR parameters for result sets, the update counts should be exhausted before calling getResultList to retrieve the result set. Alternatively, the REF_CURSOR result set can be retrieved through getOutputParameterValue. Result set mappings will be applied to results corresponding to REF_CURSOR parameters in the order the REF_CURSOR parameters were registered with the query.

In the simplest case, where results are returned only via INOUT and OUT parameters, execute can be followed immediately by calls to getOutputParameterValue.

3.12. Summary of Exceptions

The following is a summary of the exceptions defined by this specification:

PersistenceException

The PersistenceException is thrown by the persistence provider when a problem occurs. It may be thrown to report that the invoked operation could not complete because of an unexpected error (e.g., failure of the persistence provider to open a database connection).

All other exceptions defined by this specification are subclasses of the PersistenceException. All instances of PersistenceException except for instances of NoResultException, NonUniqueResultException, LockTimeoutException , and QueryTimeoutException will cause the current transaction, if one is active and the persistence context has been joined to it, to be marked for rollback.

TransactionRequiredException

The TransactionRequiredException is thrown by the persistence provider when a transaction is required but is not active.

OptimisticLockException

The OptimisticLockException is thrown by the persistence provider when an optimistic locking conflict occurs. This exception may be thrown as part of an API call, at flush, or at commit time. The current transaction, if one is active, will be marked for rollback.

PessimisticLockException

The PessimisticLockException is thrown by the persistence provider when a pessimistic locking conflict occurs. The current transaction will be marked for rollback. Typically the PessimisticLockException occurs because the database transaction has been rolled back due to deadlock or because the database uses transaction-level rollback when a pessimistic lock cannot be granted.

LockTimeoutException

The LockTimeoutException is thrown by the persistence provider when a pessimistic locking conflict occurs that does not result in transaction rollback. Typically this occurs because the database uses statement-level rollback when a pessimistic lock cannot be granted (and there is no deadlock). The LockTimeoutException does not cause the current transaction to be marked for rollback.

RollbackException

The RollbackException is thrown by the persistence provider when EntityTransaction.commit fails.

EntityExistsException

The EntityExistsException may thrown by the persistence provider when the persist operation is invoked and the entity already exists. The EntityExistsException may be thrown when the persist operation is invoked, or the EntityExistsException or another PersistenceException may be thrown at commit time. The current transaction, if one is active and the persistence context has been joined to it, will be marked for rollback.

EntityNotFoundException

The EntityNotFoundException is thrown by the persistence provider when an entity reference obtained by getReference is accessed but the entity does not exist. It is thrown by the refresh operation when the entity no longer exists in the database. It is also thrown by the lock operation when pessimistic locking is used and the entity no longer exists in the database. The current transaction, if one is active and the persistence context has been joined to it, will be marked for rollback.

NoResultException

The NoResultException is thrown by the persistence provider when Query.getSingleResult is invoked and there is no result to return. This exception will not cause the current transaction, if one is active, to be marked for rollback.

NonUniqueResultException

The NonUniqueResultException is thrown by the persistence provider when Query.getSingleResult or Query.getSingleResultOrNull is invoked and there is more than one result from the query. This exception will not cause the current transaction, if one is active, to be marked for rollback.

QueryTimeoutException

The QueryTimeoutException is thrown by the persistence provider when a query times out and only the statement is rolled back. The QueryTimeoutException does not cause the current transaction, if one is active, to be marked for rollback.

4. Query Language

The Jakarta Persistence query language is a string-based query language used to define queries over entities and their persistent state. It enables the application developer to specify the semantics of queries in a portable way, independent of the particular database schema in use in an enterprise environment. The full range of the language may be used in both static and dynamic queries.

This chapter provides the full definition of the Jakarta Persistence query language.

4.1. Overview

The Jakarta Persistence query language is a query specification language for string-based dynamic queries and static queries expressed through metadata. It is used to define queries over the persistent entities defined by this specification and their persistent state and relationships.

The Jakarta Persistence query language can be compiled to a target language, such as SQL, of a database or other persistent store. This allows the execution of queries to be shifted to the native language facilities provided by the database, instead of requiring queries to be executed on the runtime representation of the entity state. As a result, query methods can be optimizable as well as portable.

The query language uses the abstract persistence schema of entities, including their embedded objects and relationships, for its data model, and it defines operators and expressions based on this data model. It uses a SQL-like syntax to select objects or values based on abstract schema types and relationships. It is possible to parse and validate queries before entities are deployed.

The term abstract persistence schema refers to the persistent schema abstraction (persistent entities, their state, and their relationships) over which Jakarta Persistence queries operate. Queries over this persistent schema abstraction are translated into queries that are executed over the database schema to which entities are mapped.

Queries may be defined in metadata annotations or the XML descriptor. The abstract schema types of a set of entities can be used in a query if the entities are defined in the same persistence unit as the query. Path expressions allow for navigation over relationships defined in the persistence unit.

A persistence unit defines the set of all classes that are related or grouped by the application and which must be colocated in their mapping to a single database.

4.2. Statement Types

A Jakarta Persistence query language statement may be either a select statement, an update statement, or a delete statement.

This chapter refers to all such statements as “queries”. Where it is important to distinguish among statement types, the specific statement type is referenced.

In BNF syntax, a query language statement is defined as:

QL_statement ::= select_statement | update_statement | delete_statement

Any Jakarta Persistence query language statement may be constructed dynamically or may be statically defined in a metadata annotation or XML descriptor element.

All statement types may have parameters.

4.2.1. Select Statements

A select query is a string with the following clauses:

  • a SELECT clause, which determines the type of the objects or values to be selected.

  • a FROM clause, which provides declarations that designate the domain to which the expressions specified in the other clauses of the query apply.

  • an optional WHERE clause, which may be used to restrict the results that are returned by the query.

  • an optional GROUP BY clause, which allows query results to be aggregated in terms of groups.

  • an optional HAVING clause, which allows filtering over aggregated groups.

  • an optional ORDER BY clause, which may be used to order the results that are returned by the query.

In BNF syntax, a select query is defined by:

select_query ::= [select_clause]? from_clause [where_clause] [groupby_clause] [having_clause] [orderby_clause]

Every select statement has a FROM clause. The square brackets [] in the BNF indicate that the other clauses are optional.

4.2.1.1. Set Operators in Select Statements

A select statement may be a single select query, or it may combine multiple select queries using the binary left-associative operators UNION, UNION ALL, INTERSECT, INTERSECT ALL, EXCEPT, and EXCEPT ALL. The semantics of these operators are identical to SQL. [62]

The full syntax for a select statement is defined by:

select_statement ::= union
union ::= intersection | union {UNION [ALL] | EXCEPT [ALL]} intersection
intersection ::= query_expression | intersection INTERSECT [ALL] query_expression
query_expression ::= select_query | (union)

A provider is only required to support select statements where every constituent select query has the same number of items in the select clause, and where corresponding items in the select clauses of the constituent select queries either:

  • have exactly the same type, as defined by Section 4.9.1, or

  • are entity types which inherit a common entity type, as defined by Section 2.13.

4.2.2. Update and Delete Statements

Update and delete statements provide bulk operations over sets of entities.

In BNF syntax, these operations are defined by:

update_statement ::= update_clause [where_clause]
delete_statement ::= delete_clause [where_clause]

The update and delete clauses determine the type of the entities to be updated or deleted. The WHERE clause may be used to restrict the scope of the update or delete operation.

Update and delete statements are described further in Section 4.11.

4.3. Abstract Schema Types and Query Domains

The Jakarta Persistence query language is a typed language, and every expression has a type. The type of an expression is derived from the structure of the expression, the abstract schema types of the identification variable declarations, the types to which the persistent attributes evaluate, and the types of literals.

The abstract schema type of an entity or embeddable is derived from its class and the metadata information provided by Java language annotations or in the XML descriptor.

Informally, the abstract schema type of an entity or embeddable can be characterized as follows:

  • For every non-relationship persistent field or get accessor method (for a persistent property) of the class, there is a field (“state field”) whose abstract schema type corresponds to that of the field or the result type of the accessor method.

  • For every persistent relationship field or get accessor method (for a persistent relationship property) of the class, there is a field (“association field”) whose type is the abstract schema type of the related entity (or, if the relationship is a one-to-many or many-to-many, a collection of such).

Abstract schema types are specific to the query language data model. The persistence provider is not required to implement or otherwise materialize an abstract schema type.

The domain of a query consists of the abstract schema types of all entities and embeddables that are defined in the same persistence unit.

The domain of a query may be restricted by the navigability of the relationships of the entity and associated embeddable classes on which it is based. The association fields of an entity’s or embeddable’s abstract schema type determine navigability. Using the association fields and their values, a query can select related entities and use their abstract schema types in the query.

4.3.1. Naming

Entities are designated in query strings by their entity names. The entity name is defined by the name element of the Entity annotation (or the entity-name XML descriptor element), and defaults to the unqualified name of the entity class. Entity names are scoped within the persistence unit and must be unique within the persistence unit.

4.3.2. Example

This example assumes that the application developer provides several entity classes, representing orders, products, and line items, and an embeddable address class representing shipping addresses and billing addresses. The abstract schema types for the entities are Order, Product, and LineItem respectively. There is a one-to-many relationship between Order and LineItem. The entity LineItem is related to Product in a many-to-one relationship. The classes are logically in the same persistence unit, as shown in Figure 1.

Queries to select orders can be defined by navigating over the association fields and state fields defined by Order and LineItem. A query to find all orders with pending line items might be written as follows:

SELECT DISTINCT o
FROM Order AS o JOIN o.lineItems AS l
WHERE l.shipped = FALSE
Image
Figure 1. Abstract persistence schema of several entities defined in the same persistence unit.

This query navigates over the association field lineItems of the abstract schema type Order to find line items, and uses the state field shipped of LineItem to select those orders that have at least one line item that has not yet shipped. (Note that this query does not select orders that have no line items.)

Although reserved identifiers, such as DISTINCT, FROM, AS, JOIN, WHERE, and FALSE appear in upper case in this example, reserved identifiers are case insensitive.[63]

The SELECT clause of this example designates the return type of this query to be of type Order.

Because the same persistence unit defines the abstract persistence schema of the related entities, the developer can also specify a query over orders that utilizes the abstract schema type for products, and hence the state fields and association fields of both the abstract schema types Order and Product. For example, if the abstract schema type Product has a state field named productType, a query over orders can be specified using this state field. Such a query might be to find all orders for products with product type office supplies. A query for this might be as follows.

SELECT DISTINCT o
FROM Order o JOIN o.lineItems l JOIN l.product p
WHERE p.productType = 'office_supplies'

Because Order is related to Product by means of the relationships between Order and LineItem and between LineItem and Product, navigation using the association fields lineItems and product is used to express the query. This query is specified by using the entity name Order, which designates the abstract schema type over which the query ranges. The basis for the navigation is provided by the association fields lineItems and product of the abstract schema types Order and LineItem respectively.

4.4. The FROM Clause and Navigational Declarations

The FROM clause of a query defines the domain of the query:

  • one or more named entity abstract schema types, as specified below in Section 4.4.3, together with

  • zero or more joined associations and collections, as specified below in Section 4.4.5.

An identification variable is an identifier declared in the FROM clause of a query. Each identification variable is assigned an abstract schema type. Each element of the domain may declare an identification variable.

  • If the domain has exactly one named entity abstract schema type and no joins, then the named entity does not require an explicit identification variable, and its identification variable defaults to the implicit identification variable, this.

  • Otherwise, every element of the FROM clause—​that is, every named entity abstract schema types and every join—​must declare an identification variable.

from_clause ::=
    FROM {this_implicit_variable | identification_variable_declarations}

this_implicit_variable ::= entity_name

identification_variable_declarations ::=
    identification_variable_declaration
    {, {identification_variable_declaration | collection_member_declaration}}*

identification_variable_declaration ::= range_variable_declaration {join | fetch_join}*

range_variable_declaration ::= entity_name [AS] identification_variable

join ::= range_join | path_join

range_join ::= join_spec range_variable_declaration [join_condition]

path_join ::=
    join_spec join_association_path_expression [AS] identification_variable [join_condition]

fetch_join ::= join_spec FETCH join_association_path_expression

join_spec ::= [INNER | LEFT [OUTER]] JOIN

join_association_path_expression ::=
    join_collection_valued_path_expression |
    join_single_valued_path_expression |
    TREAT(join_collection_valued_path_expression AS subtype) |
    TREAT(join_single_valued_path_expression AS subtype)

join_collection_valued_path_expression ::= [identification_variable.]{single_valued_embeddable_object_field.}*collection_valued_field

join_single_valued_path_expression ::= [identification_variable.]{single_valued_embeddable_object_field.}*single_valued_object_field

join_condition ::= ON conditional_expression

collection_member_declaration ::= IN (collection_valued_path_expression) [AS] identification_variable

The following subsections discuss the constructs used in the FROM clause.

4.4.1. Identifiers

An identifier is a character sequence of unlimited length. The character sequence must begin with a Java identifier start character, and all other characters must be Java identifier part characters. An identifier start character is any character for which the method Character.isJavaIdentifierStart returns true. This includes the underscore (_) character and the dollar sign ($) character. An identifier part character is any character for which the method Character.isJavaIdentifierPart returns true. The question mark (?) character is reserved for use by the Jakarta Persistence query language.

The following[64] are reserved identifiers: ABS, ALL, AND, ANY, AS, ASC, AVG, BETWEEN, BIT_LENGTH, BOTH, BY, CASE, CEILING, CHAR_LENGTH, CHARACTER_LENGTH, CLASS, COALESCE, CONCAT, COUNT, CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, DELETE, DESC, DISTINCT, ELSE, EMPTY, END, ENTRY, ESCAPE, EXISTS, EXP, EXTRACT, FALSE, FETCH, FIRST, FLOOR, FROM, FUNCTION, GROUP, HAVING, IN, INDEX, INNER, IS, JOIN, KEY, LEADING, LAST, LEFT, LENGTH, LIKE, LOCAL, LN, LOCATE, LOWER, MAX, MEMBER, MIN, MOD, NEW, NOT, NULL, NULLS, NULLIF, OBJECT, OF, ON, OR, ORDER, OUTER, POSITION, POWER, REPLACE, RIGHT, ROUND, SELECT, SET, SIGN, SIZE, SOME, SQRT, SUBSTRING, SUM, THEN, TRAILING, TREAT, TRIM, TRUE, TYPE, UNKNOWN, UPDATE, UPPER, VALUE, WHEN, WHERE.

Reserved identifiers are case-insensitive. Reserved identifiers must not be used as identification variables or result variables (see Section 4.9).

It is recommended that SQL keywords other than those listed above not be used as identification variables in queries because they may be used as reserved identifiers in future releases of this specification.

4.4.2. Identification Variables

An identification variable is a valid identifier declared in the FROM clause of a query.

Every identification variable must be declared in the FROM clause, except for the implicit identification variable this. Identification variables are never declared in other clauses.

An identification variable must not be a reserved identifier.

An identification variable may have the same name as an entity.

Identification variables are case-insensitive.

An identification variable evaluates to a value of the type of the expression used in declaring the variable. For example, consider the previous query:

SELECT DISTINCT o
FROM Order o JOIN o.lineItems l JOIN l.product p
WHERE p.productType = 'office_supplies'

In the FROM clause declaration o.lineItems l, the identification variable l evaluates to any LineItem value directly reachable from Order. The association field lineItems is a collection of instances of the abstract schema type LineItem and the identification variable l refers to an element of this collection. The type of l is the abstract schema type of LineItem.

An identification variable can range over an entity, embeddable, or basic abstract schema type. An identification variable designates an instance of an abstract schema type or an element of a collection of abstract schema type instances.

Note that for identification variables referring to an instance of an association or collection represented as a java.util.Map, the identification variable is of the abstract schema type of the map value.

An identification variable always designates a reference to a single value. It is declared in one of three ways: in a range variable declaration, in a join clause, or in a collection member declaration. The identification variable declarations are evaluated from left to right in the FROM clause, and an identification variable declaration can use the result of a preceding identification variable declaration of the query string.

All identification variables used in the SELECT, WHERE, ORDER BY, GROUP BY, or HAVING clause of a SELECT or DELETE statement must be declared in the FROM clause. The identification variables used in the WHERE clause of an UPDATE statement must be declared in the UPDATE clause.

Identification variables are existentially quantified in these clauses. This means that an identification variable represents a member of a collection or an instance of an entity’s abstract schema type. An identification variable never designates a collection in its entirety.

An identification variable is scoped to the query (or subquery) in which it is defined and is also visible to any subqueries within that query scope that do not define an identification variable of the same name.

4.4.3. Range Variable Declarations

A range variable declaration introduces a query domain element ranging over a given named entity abstract schema type, with an associated identification variable.

The syntax for declaring an identification variable as a range variable is similar to that of SQL; optionally, it may use the AS keyword. A range variable declaration designates an entity abstract schema type by its entity name, as defined above in Section 4.3.1.[65]

range_variable_declaration ::= entity_name [AS] identification_variable

The entity name in a range variable declaration is case-sensitive.

Range variable declarations allow the developer to designate a “root” for objects which may not be reachable by navigation.

In order to select values by comparing more than one instance of an entity abstract schema type, more than one identification variable ranging over the abstract schema type is needed in the FROM clause.

The following query returns orders whose quantity is greater than the order quantity for John Smith. This example illustrates the use of two different identification variables in the FROM clause, both of the abstract schema type Order. The SELECT clause of this query determines that it is the orders with quantities larger than John Smith’s that are returned.

SELECT DISTINCT o1
FROM Order o1, Order o2
WHERE o1.quantity > o2.quantity AND
 o2.customer.lastname = 'Smith' AND
 o2.customer.firstname= 'John'

If the query domain is a single entity abstract schema type, the range variable declaration is optional. These queries are equivalent:

SELECT quantity
FROM Order
WHERE customer.lastname = 'Smith'
  AND customer.firstname= 'John'
SELECT this.quantity
FROM Order
WHERE this.customer.lastname = 'Smith'
  AND this.customer.firstname= 'John'
SELECT ord.quantity
FROM Order AS ord
WHERE ord.customer.lastname = 'Smith'
  AND ord.customer.firstname= 'John'

Otherwise, if the query domain has more than one element, each named entity abstract schema type listed in the FROM clause must be a range variable declaration, and the implicit identification variable is not implicitly assigned an abstract schema type.

4.4.4. Path Expressions

A path expression is a sequence of identifiers uniquely identifying a state field or association field of an element of the query domain.

A path expression may begin with a reference to an identification variable, followed by the navigation operator (.). If the first element of a path expression is not an identification variable, then the path expression is interpreted exactly as if it began with the implicit identification variable this.

The remaining elements of the path expression are interpreted as references to state fields or association fields in the context of the abstract schema type assigned to the identification variable—​or to this, if the path expression does not begin with an identification variable.

A reference to a state field or association field in a path expression is case-sensitive.

The type of the path expression is the type computed as the result of navigation; that is, the type of the state field or association field to which the expression navigates. The type of a path expression that navigates to an association field may be specified as a subtype of the declared type of the association field by means of the TREAT operator. See Section 4.4.9.

An identification variable qualified by the KEY, VALUE, or ENTRY operator is a path expression. The KEY, VALUE, and ENTRY operators may only be applied to identification variables that correspond to map-valued associations or map-valued element collections. The type of the path expression is the type computed as the result of the operation; that is, the abstract schema type of the field that is the value of the KEY, VALUE, or ENTRY operator (the map key, map value, or map entry respectively).[66]

In the following query, photos is a map from photo label to filename.

SELECT i.name, VALUE(p)
FROM Item i JOIN i.photos p
WHERE KEY(p) LIKE '%egret'

In the above query the identification variable p designates an abstract schema type corresponding to the map value. The results of VALUE(p) and KEY(p) are the map value and the map key associated with p, respectively. The following query is equivalent:

SELECT i.name, p
FROM Item i JOIN i.photos p
WHERE KEY(p) LIKE '%egret'

A path expression using the KEY or VALUE operator can be further composed. A path expression using the ENTRY operator is terminal. It cannot be further composed and can only appear in the SELECT list of a query.

The syntax for qualified identification variables is as follows.

qualified_identification_variable ::=
    map_field_identification_variable |
    ENTRY(identification_variable)

map_field_identification_variable ::=
    KEY(identification_variable) |
    VALUE(identification_variable)

Depending on navigability, a path expression that leads to an association field or to a field whose type is an embeddable class may be further composed. Path expressions can be composed from other path expressions if the original path expression evaluates to a single-valued type (not a collection).

In the following example, simple data model with Employee, ContactInfo, Address and Phone classes is used:

@Entity
public class Employee {
    @Id int id;
    @Embedded
    private ContactInfo contactInfo;
}

@Entity
public class Phone {
    @Id
    private int id;
    private String vendor;
}

@Embeddable
public class ContactInfo {
    @Embedded
    private Address address;
    @ManyToMany
    private List<Phone> phones;
}

@Embeddable
public class Address {
    private String street;
    private String city;
    private String state;
    private String zipcode;
}

The contactInfo field denotes an embeddable class consisting of an address and set of phones.

SELECT p.vendor
FROM Employee e JOIN e.contactInfo.phones p
WHERE e.contactInfo.address.zipcode = '95054'

Path expression navigability is composed using “inner join” semantics. That is, if the value of a non-terminal field in the path expression is null, the path is considered to have no value, and does not participate in the determination of the result.

The following query is equivalent to the query above:

SELECT p.vendor
FROM Employee e JOIN e.contactInfo c JOIN c.phones p
WHERE e.contactInfo.address.zipcode = '95054'
4.4.4.1. Path Expression Syntax

The syntax for single-valued path expressions and collection-valued path expressions is as follows.

An identification variable used in a single_valued_object_path_expression or in a collection_valued_path_expression may be an unqualified identification variable or an identification variable to which the KEY or VALUE function has been applied.

general_identification_variable ::=
    identification_variable |
    map_field_identification_variable

The type of an entity-valued path expression or an entity-valued subpath of a path expression used in a WHERE clause may be specified as a subtype of the corresponding declared type by means of the TREAT operator. See Section 4.4.9.

general_subpath ::= simple_subpath | treated_subpath{.single_valued_object_field}*

simple_subpath ::=
    general_identification_variable |
    general_identification_variable{.single_valued_object_field}*

treated_subpath ::= TREAT(general_subpath AS subtype)

single_valued_path_expression ::=
    qualified_identification_variable |
    TREAT(qualified_identification_variable AS subtype) |
    state_field_path_expression |
    single_valued_object_path_expression

state_field_path_expression ::= [general_subpath.]state_field

state_valued_path_expression ::= state_field_path_expression | general_identification_variable

single_valued_object_path_expression ::= general_subpath.single_valued_object_field

collection_valued_path_expression ::= general_subpath.collection_valued_field

A single_valued_object_field is designated by the name of an association field in a one-to-one or many-to-one relationship or a field of embeddable class type. The type of a single_valued_object_field is the abstract schema type of the related entity or embeddable class.

A single_valued_embeddable_object_field is designated by the name of a field of embeddable class type.

A state_field is designated by the name of an entity or embeddable class state field that corresponds to a basic type.

A collection_valued_field is designated by the name of an association field in a one-to-many or a many-to-many relationship or by the name of an element collection field. The type of a collection_valued_field is a collection of values of the abstract schema type of the related entity or element type.

It is syntactically illegal to compose a path expression from a path expression that evaluates to a collection. For example, if o designates Order, the path expression o.lineItems.product is illegal since navigation to lineItems results in a collection. This case should produce an error when the query string is verified. To handle such a navigation, an identification variable must be declared in the FROM clause to range over the elements of the lineItems collection. Another path expression must be used to navigate over each such element in the WHERE clause of the query, as in the following:

SELECT DISTINCT l.product
FROM Order AS o JOIN o.lineItems l

A collection_valued_path_expression may only occur in:

  • the FROM clause of a query,

  • an empty_collection_comparison_expression,

  • a collection_member_expression, or

  • as an argument to the SIZE operator.

4.4.5. Joins

JPQL defines the following varieties of join:

  • inner joins, and.

  • left outer joins.[67]

The semantics of each variety of join is identical to SQL, and the syntax is borrowed from ANSI SQL.

Every join has a target, either:

  • an entity-valued path expression, or

  • an entity type (that is, range variable declaration, as already specified in Section 4.4.3).

An inner join may be implicitly specified by the use of a cartesian product in the FROM clause and a join condition in the WHERE clause. In the absence of a join condition, this reduces to the cartesian product.

The main use case for this generalized style of join is when a join condition does not involve a foreign key relationship mapped to an association between entities.

Example:

SELECT c FROM Customer c, Employee e WHERE c.hatsize = e.shoesize

This style of inner join (sometimes called a "theta" join) is less typical than explicitly defined joins over relationships.

The syntax for explicit join operations is given by:

join ::= range_join | path_join

range_join ::= join_spec range_variable_declaration [join_condition]

path_join ::=
    join_spec join_association_path_expression [AS] identification_variable [join_condition]

fetch_join ::= join_spec FETCH join_association_path_expression

join_spec ::= [INNER | LEFT [OUTER]] JOIN

join_association_path_expression ::=
    join_collection_valued_path_expression |
    join_single_valued_path_expression |
    TREAT(join_collection_valued_path_expression `AS` subtype) |
    TREAT(join_single_valued_path_expression AS subtype)

join_collection_valued_path_expression ::=
    [identification_variable.]{single_valued_embeddable_object_field.}*collection_valued_field

join_single_valued_path_expression ::=
    [identification_variable.]{single_valued_embeddable_object_field.}*single_valued_object_field

join_condition ::= ON conditional_expression

The inner and outer join operation types described in Section 4.4.5.1, Section 4.4.5.2, and Section 4.4.5.3 are supported.

4.4.5.1. Inner Joins

The syntax for an inner join to an entity type is given by:

[INNER] JOIN range_variable_declaration [join_condition]

The keyword INNER is optional and does not affect the semantics of the query.

SELECT c
FROM Customer c
    JOIN Order o ON o.customer.id = c.id
WHERE c.status = 1

Or, equivalently:

SELECT c
FROM Customer c
    INNER JOIN Order o ON o.customer.id = c.id
WHERE c.status = 1

These queries are equivalent to the following query involving an implicit "theta" join:

SELECT c
FROM Customer c, Order o
WHERE o.customer.id = c.id AND c.status = 1

The syntax for an inner join over an association is given by:

[INNER] JOIN join_association_path_expression [AS] identification_variable [join_condition]

For example, the query below joins over the relationship between customers and orders. This type of join typically equates to a join over a foreign key relationship in the database.

SELECT c
FROM Customer c
   JOIN c.orders o
WHERE c.status = 1

Equivalently:

SELECT c
FROM Customer c
    INNER JOIN c.orders o
WHERE c.status = 1

This is equivalent to the following query using the earlier IN construct, defined in [4]. It selects those customers of status 1 for which at least one order exists:

SELECT OBJECT(c)
FROM Customer c, IN(c.orders) o
WHERE c.status = 1

The query below joins over Employee, ContactInfo and Phone. ContactInfo is an embeddable class that consists of an address and set of phones. Phone is an entity.

SELECT p.vendor
FROM Employee e JOIN e.contactInfo c JOIN c.phones p
WHERE c.address.zipcode = '95054'

A join condition may be specified for an inner join. This is equivalent to specification of the same condition in the WHERE clause.

4.4.5.2. Outer Joins

The syntax for an outer join to an entity type is given by:

LEFT [OUTER] JOIN range_variable_declaration [join_condition]

The keyword OUTER is optional and does not affect the semantics of the query.

SELECT c
FROM Customer c
    LEFT JOIN Order o ON o.customer.id = c.id
WHERE c.status = 1

Or, equivalently:

SELECT c
FROM Customer c
    LEFT OUTER JOIN Order o ON o.customer.id = c.id
WHERE c.status = 1

Outer joins enable the retrieval of a set of entities where matching values in the join condition may be absent. For example, the queries above return Customer instances with no matching Order.

The syntax for an outer join over an association is given by:

LEFT [OUTER] JOIN join_association_path_expression [AS] identification_variable [join_condition]

An association outer join without no explicit join_condition has an implicit join condition inferred from the foreign key relationship mapped by the join_association_path_expression. Typically, a JPQL join of this form is translated to a SQL outer join with an ON condition specifying the foreign key relationship, as in the following examples.

Jakarta Persistence query language:

SELECT s.name, COUNT(p)
FROM Suppliers s LEFT JOIN s.products p
GROUP BY s.name

SQL:

SELECT s.name, COUNT(p.id)
FROM Suppliers s LEFT JOIN Products p
    ON s.id = p.supplierId
GROUP By s.name

An explicit join_condition (that is, an ON condition in the JOIN) results in an additional restriction in the ON condition of the generated SQL.

Jakarta Persistence query language:

SELECT s.name, COUNT(p)
FROM Suppliers s LEFT JOIN s.products p
    ON p.status = 'inStock'
GROUP BY s.name

SQL:

SELECT s.name, COUNT(p.id)
FROM Suppliers s LEFT JOIN Products p
    ON s.id = p.supplierId AND p.status = 'inStock'
GROUP BY s.name

Note that the result of this query will be different from that of the following query:

SELECT s.name, COUNT(p)
FROM Suppliers s LEFT JOIN s.products p
WHERE p.status = 'inStock'
GROUP BY s.name

The result of the latter query will exclude suppliers who have no products in stock whereas the former query will include them.

An important use case for LEFT JOIN is in enabling the prefetching of related data items as a side effect of a query. This is accomplished by specifying the LEFT JOIN as a fetch join, that is, LEFT JOIN FETCH, as described below.

4.4.5.3. Fetch Joins

A fetch join clause in a query results in eager fetching of an association or element collection as a side effect of execution of the query.

The syntax for a fetch join is given by:

fetch_join ::= [LEFT [OUTER] | INNER] JOIN FETCH join_association_path_expression

A fetch join must be an INNER or LEFT (OUTER) join. A fetch join does not have an explicit join condition or identification variable.

The association referenced by the right side of the fetch join clause must be an association or element collection that is referenced from an entity or embeddable that is returned as a result of the query. It is not permitted to specify an identification variable for the objects referenced by the right side of the fetch join clause, and hence references to the implicitly fetched entities or elements cannot appear elsewhere in the query.

The following query returns a set of departments. As a side effect, the associated employees for those departments are also retrieved, even though they are not part of the explicit query result. The initialization of the persistent state or relationship fields or properties of the objects that are retrieved as a result of a fetch join is determined by the metadata for that class—in this example, the Employee entity class.

SELECT d
FROM Department d LEFT JOIN FETCH d.employees
WHERE d.deptno = 1

A fetch join has the same join semantics as the corresponding inner or outer join, except that the related objects specified on the right-hand side of the join operation are not returned in the query result or otherwise referenced in the query. Hence, for example, if department 1 has five employees, the above query returns five references to the department 1 entity.

The fetch join construct must not be used in the FROM clause of a subquery.

4.4.6. Collection Member Declarations

An identification variable declared by a collection_member_declaration ranges over values of a collection obtained by navigation using a path expression.

An identification variable of a collection member declaration is declared using a special operator, the reserved identifier IN. The argument to the IN operator is a collection-valued path expression. The path expression evaluates to a collection type specified as a result of navigation to a collection-valued association field of an entity or embeddable class abstract schema type.

The syntax for declaring a collection member identification variable is as follows:

collection_member_declaration ::=
    IN (collection_valued_path_expression) [AS] identification_variable

For example, the query

SELECT DISTINCT o
FROM Order o JOIN o.lineItems l
WHERE l.product.productType = 'office_supplies'

can equivalently be expressed as follows, using the IN operator:

SELECT DISTINCT o
FROM Order o, IN(o.lineItems) l
WHERE l.product.productType = 'office_supplies'

In this example, lineItems is the name of an association field whose value is a collection of instances of the abstract schema type LineItem. The identification variable l designates a member of this collection, a single LineItem abstract schema type instance. In this example, o is an identification variable of the abstract schema type Order.

4.4.7. FROM Clause and SQL

The Jakarta Persistence query language treats the FROM clause similarly to SQL in that the declared identification variables affect the results of the query even if they are not used in the WHERE clause. Application developers should use caution in defining identification variables because the domain of the query can depend on whether there are any values of the declared type.

For example, the FROM clause below defines a query over all orders that have line items and existing products. If there are no Product instances in the database, the domain of the query is empty and no order is selected.

SELECT o
FROM Order AS o JOIN o.lineItems l JOIN l.product p

4.4.8. Polymorphism

Jakarta Persistence queries are automatically polymorphic. The FROM clause of a query designates not only instances of the specific entity class(es) to which it explicitly refers but instances of subclasses of those classes as well. The instances returned by a query thus include instances of the subclasses that satisfy the query criteria.

Non-polymorphic queries or queries whose polymorphism is restricted can be specified using entity type expressions in the WHERE clause to restrict the domain of the query. See Section 4.7.12.

4.4.9. Downcasting

The use of the TREAT operator is supported for downcasting within path expressions in the FROM and WHERE clauses. Use of the TREAT operator allows access to subclass-specific state.

If during query execution the first argument to the TREAT operator is not a subtype (proper or improper) of the target type, the path is considered to have no value, and does not participate in the determination of the result. That is, in the case of a join, the referenced object does not participate in the result, and in the case of a restriction, the associated predicate is false. Use of the TREAT operator therefore also has the effect of filtering on the specified type (and its subtypes) as well as performing the downcast. If the target type is not a subtype (proper or improper) of the static type of the first argument, the query is invalid.

Examples:

SELECT b.name, b.ISBN
FROM Order o JOIN TREAT(o.product AS Book) b

SELECT e FROM Employee e JOIN TREAT(e.projects AS LargeProject) lp
WHERE lp.budget > 1000

SELECT e FROM Employee e JOIN e.projects p
WHERE TREAT(p AS LargeProject).budget > 1000
    OR TREAT(p AS SmallProject).name LIKE 'Persist%'
    OR p.description LIKE "cost overrun"

SELECT e FROM Employee e
WHERE TREAT(e AS Exempt).vacationDays > 10
    OR TREAT(e AS Contractor).hours > 100

4.5. WHERE Clause

The WHERE clause of a query consists of a conditional expression used to select objects or values that satisfy the expression. The WHERE clause restricts the result of a select statement or the scope of an update or delete operation.

A WHERE clause is defined as follows:

where_clause ::= WHERE conditional_expression

The GROUP BY construct enables the aggregation of values according to the properties of an entity class. The HAVING construct enables conditions to be specified that further restrict the query result as restrictions upon the groups.

The syntax of the HAVING clause is as follows:

having_clause ::= HAVING conditional_expression

The GROUP BY and HAVING constructs are further discussed in Section 4.8.

4.6. Conditional Expressions

The following sections describe language constructs that can be used in a conditional expression of the WHERE clause, the HAVING clause, or in an ON condition.

State fields that are mapped in serialized form or as lobs cannot be portably used in conditional [68].

4.6.1. Conditional Expression Composition

Conditional expressions are composed of other conditional expressions, comparison operations, logical operations, path expressions that evaluate to boolean values, boolean literals, and boolean input parameters.

The scalar expressions described in Section 4.7 can be used in conditional expressions.

Aggregate functions can only be used in conditional expressions in a HAVING clause. See Section 4.8.

Standard bracketing () for ordering expression evaluation is supported.

Conditional expressions are defined as follows:

conditional_expression ::= conditional_term | conditional_expression OR conditional_term
conditional_term ::= conditional_factor | conditional_term AND conditional_factor
conditional_factor ::= [NOT] conditional_primary
conditional_primary ::= simple_cond_expression | (conditional_expression)
simple_cond_expression ::=
    comparison_expression |
    between_expression |
    in_expression |
    like_expression |
    null_comparison_expression |
    empty_collection_comparison_expression |
    collection_member_expression |
    exists_expression

4.6.2. Operators and Operator Precedence

The operators are listed below in order of decreasing precedence.

  • Navigation operator (.)

  • Arithmetic operators:

    • +, - unary

    • *, / multiplication and division

    • +, - addition and subtraction

  • String concatenation (||)

  • Comparison operators: =, >, >=, < , <=, <> (not equal), [NOT] BETWEEN, [NOT] LIKE, [NOT] IN, IS [NOT] NULL, IS [NOT] EMPTY, [NOT] MEMBER [OF], [NOT] EXISTS

  • Logical operators:

    • NOT

    • AND

    • OR

The following sections describe operators used in specific expressions.

4.6.3. Comparison Expressions

The syntax for the use of comparison expressions in a conditional expression is as follows[69]:

comparison_expression ::=
    string_expression comparison_operator {string_expression | all_or_any_expression} |
    boolean_expression {= | <>} {boolean_expression | all_or_any_expression} |
    enum_expression {= | <>} {enum_expression | all_or_any_expression} |
    datetime_expression comparison_operator
        {datetime_expression | all_or_any_expression} |
    entity_expression {= | <>} {entity_expression | all_or_any_expression} |
    arithmetic_expression comparison_operator
        {arithmetic_expression | all_or_any_expression} |
    entity_id_or_version_function {= | <>} input_parameter |
    entity_type_expression {= | <>} entity_type_expression}

comparison_operator ::= = | > | >= | < | <= | <>

Examples:

item.cost * 1.08 <= 100.00
CONCAT(person.lastName, ', ', person.firstName)) = 'Jones, Sam'
TYPE(e) = ExemptEmployee

4.6.4. Between Expressions

The syntax for the use of the comparison operator [NOT] BETWEEN in a conditional expression is as follows:

 between_expression ::=
    arithmetic_expression [NOT] BETWEEN arithmetic_expression AND arithmetic_expression |
    string_expression [NOT] BETWEEN string_expression AND string_expression |
    datetime_expression [NOT] BETWEEN datetime_expression AND datetime_expression

The BETWEEN expression

x BETWEEN y AND z

is semantically equivalent to:

y <= x AND x <= z

The rules for unknown and NULL values in comparison operations apply. See Section 4.6.13.

Examples:

  • p.age BETWEEN 15 and 19 is equivalent to p.age >= 15 AND p.age <= 19

  • p.age NOT BETWEEN 15 and 19 is equivalent to p.age < 15 OR p.age > 19

In the following example, transactionHistory is a list of credit card transactions defined using an order column.

SELECT t
FROM CreditCard c JOIN c.transactionHistory t
WHERE c.holder.name = 'John Doe' AND INDEX(t) BETWEEN 0 AND 9

4.6.5. In Expressions

The syntax for the use of the comparison operator [NOT] IN in a conditional expression is as follows:

in_expression ::=
    {state_valued_path_expression | type_discriminator} [NOT] IN
        {(in_item {, in_item}*) | (subquery) | collection_valued_input_parameter}
in_item ::= literal | single_valued_input_parameter

The state_valued_path_expression must have a string, numeric, date, time, timestamp, or enum value.

The literal and/or input parameter values must be like the abstract schema type of the state_valued_path_expression in type. (See Section 4.6.14.)

The results of the subquery must be like the abstract schema type of the state_valued_path_expression in type. Subqueries are discussed in Section 4.6.12.

Example 1:

o.country IN ('UK', 'US', 'France')

is true for UK and false for Peru, and is equivalent to the expression

(o.country = 'UK') OR (o.country = 'US') OR (o.country = 'France')

Example 2:

o.country NOT IN ('UK', 'US', 'France')

is false for UK and true for Peru, and is equivalent to the expression

NOT ((o.country = 'UK') OR (o.country = 'US') OR (o.country = 'France'))

If an IN or NOT IN expression has a list of in_item expressions, there must be at least one item in the list. The value of such expressions is determined according to the following rules:

  • If the state_valued_path_expression in an IN or NOT IN expression evaluates to NULL or unknown, then the whole IN or NOT IN expression evaluates to NULL or unknown.

  • Otherwise, if the state_valued_path_expression and at least one in_item evaluate to the same value, the whole IN or NOT IN expression evaluates to true.

  • Otherwise, if the value of a state_valued_path_expression evaluates to a value distinct from the value of every in_item expression, the whole IN or NOT IN expression evaluates to:

    • false, if every in_item expression evaluates to a non-null value, or

    • NULL or unknown if at least one in_item expression evaluates to null.

The list of values may be parameterized by a collection-valued input parameter. [70] (See Section 4.7.4.)

o.country NOT IN :countries

4.6.6. Like Expressions

The syntax for the use of the comparison operator [NOT] LIKE in a conditional expression is as follows:

like_expression ::=
    string_expression [NOT] LIKE pattern_value [ESCAPE escape_character]

The string_expression must have a string value. The pattern_value is a string literal or a string-valued input parameter in which an underscore (_) stands for any single character, a percent (%) character stands for any sequence of characters (including the empty sequence), and all other characters stand for themselves. The optional escape_character is a single-character string literal or a character-valued input parameter (i.e., char or Character) and is used to escape the special meaning of the underscore and percent characters in pattern_value. [71]

Examples:

  • address.phone LIKE '12%3' is true for '123', '12993' and false for '1234'

  • asentence.word LIKE 'l_se' is true for 'lose' and false for 'loose'

  • aword.underscored LIKE '_%' ESCAPE '\' is true for '_foo' and false for 'bar'

  • address.phone NOT LIKE '12%3' is false for '123' and '12993' and true for '1234'

If the value of the string_expression or pattern_value is NULL or unknown, the value of the LIKE expression is unknown. If the escape_character is specified and is NULL, the value of the LIKE expression is unknown.

4.6.7. Null Comparison Expressions

The syntax for the use of the comparison operator IS NULL in a conditional expression is as follows:

null_comparison_expression ::=
    {single_valued_path_expression | input_parameter} IS [NOT] NULL

A null comparison expression tests whether or not the single-valued path expression or input parameter is a NULL value.

Null comparisons over instances of embeddable class types are not supported. Support for comparisons over embeddables may be added in a future release of this specification.

4.6.8. Empty Collection Comparison Expressions

The syntax for the use of the comparison operator IS EMPTY in an empty_collection_comparison_expression is as follows:

empty_collection_comparison_expression ::=
    collection_valued_path_expression IS [NOT] EMPTY

This expression tests whether or not the collection designated by the collection-valued path expression is empty (i.e, has no elements).

Example:

SELECT o
FROM Order o
WHERE o.lineItems IS EMPTY

If the value of the collection-valued path expression in an empty collection comparison expression is unknown, the value of the empty comparison expression is unknown.

4.6.9. Collection Member Expressions

The syntax for the use of the comparison operator MEMBER OF [72] in a collection_member_expression is as follows:

collection_member_expression ::=
    entity_or_value_expression [NOT] MEMBER [OF] collection_valued_path_expression
entity_or_value_expression ::=
    single_valued_object_path_expression |
    state_valued_path_expression |
    simple_entity_or_value_expression
simple_entity_or_value_expression ::=
    identification_variable |
    input_parameter |
    literal

This expression tests whether the designated value is a member of the collection specified by the collection-valued path expression.

Expressions that evaluate to embeddable types are not supported in collection member expressions. Support for use of embeddables in collection member expressions may be added in a future release of this specification.

If the collection valued path expression designates an empty collection, the value of the MEMBER OF expression is FALSE and the value of the NOT MEMBER OF expression is TRUE. Otherwise, if the value of the collection_valued_path_expression or entity_or_value_expression in the collection member expression is NULL or unknown, the value of the collection member expression is unknown.

Example:

SELECT p
FROM Person p
WHERE 'Joe' MEMBER OF p.nicknames

4.6.10. Exists Expressions

An EXISTS expression is a predicate that is true only if the result of the subquery consists of one or more values and that is false otherwise.

The syntax of an exists expression is

exists_expression ::= [NOT] EXISTS (subquery)

Example:

SELECT DISTINCT emp
FROM Employee emp
WHERE EXISTS (
    SELECT spouseEmp
    FROM Employee spouseEmp
        WHERE spouseEmp = emp.spouse)

The result of this query consists of all employees whose spouses are also employees.

4.6.11. All or Any Expressions

An ALL conditional expression is a predicate over a subquery that is true if the comparison operation is true for all values in the result of the subquery or the result of the subquery is empty. An ALL conditional expression is false if the result of the comparison is false for at least one value of the result of the subquery, and is unknown if neither true nor false.

An ANY conditional expression is a predicate over a subquery that is true if the comparison operation is true for some value in the result of the subquery. An ANY conditional expression is false if the result of the subquery is empty or if the comparison operation is false for every value in the result of the subquery, and is unknown if neither true nor false. The keyword SOME is synonymous with ANY.

The comparison operators used with ALL or ANY conditional expressions are =, <, <=, >, >=, <>. The result of the subquery must be like that of the other argument to the comparison operator in type. See Section 4.6.14.

The syntax of an ALL or ANY expression is specified as follows:

all_or_any_expression ::= {ALL | ANY | SOME} (subquery)

Example:

SELECT emp
FROM Employee emp
WHERE emp.salary > ALL (
    SELECT m.salary
    FROM Manager m
    WHERE m.department = emp.department)

The result of this query consists of all employees whose salaries exceed the salaries of all managers in their department.

4.6.12. Subqueries

Subqueries may be used in the WHERE or HAVING clause.[73]

The syntax for subqueries is as follows:

subquery ::= simple_select_clause subquery_from_clause [where_clause]
    [groupby_clause] [having_clause]
simple_select_clause ::= SELECT [DISTINCT] simple_select_expression
subquery_from_clause ::=
    FROM subselect_identification_variable_declaration
        {, subselect_identification_variable_declaration |
            collection_member_declaration}*
subselect_identification_variable_declaration ::=
    identification_variable_declaration |
    derived_path_expression [AS] identification_variable {join}* |
    derived_collection_member_declaration
simple_select_expression ::=
    single_valued_path_expression |
    scalar_expression |
    aggregate_expression |
    identification_variable
derived_path_expression ::=
    general_derived_path.single_valued_object_field |
    general_derived_path.collection_valued_field
general_derived_path ::=
    simple_derived_path |
    treated_derived_path{.single_valued_object_field}*
simple_derived_path ::= superquery_identification_variable{.single_valued_object_field}*
treated_derived_path ::= TREAT(general_derived_path AS subtype)
derived_collection_member_declaration ::=
    IN superquery_identification_variable.{single_valued_object_field.}*collection_valued_field

Examples:

SELECT DISTINCT emp
FROM Employee emp
WHERE EXISTS (
    SELECT spouseEmp
    FROM Employee spouseEmp
    WHERE spouseEmp = emp.spouse)

Note that some contexts in which a subquery can be used require that the subquery be a scalar subquery (i.e., produce a single result). This is illustrated in the following examples using numeric comparisons.

SELECT c
FROM Customer c
WHERE (SELECT AVG(o.price) FROM c.orders o) > 100

SELECT goodCustomer
FROM Customer goodCustomer
WHERE goodCustomer.balanceOwed < (
    SELECT AVG(c.balanceOwed)/2.0 FROM Customer c)

4.6.13. Null Values

When the target of a reference does not exist in the database, its value is regarded as NULL. SQL NULL semantics [2] defines the evaluation of conditional expressions containing NULL values.

The following is a brief description of these semantics:

  • Comparison or arithmetic operations with a NULL value always yield an unknown value.

  • Two NULL values are not considered to be equal, the comparison yields an unknown value.

  • Comparison or arithmetic operations with an unknown value always yield an unknown value.

  • The IS NULL and IS NOT NULL operators convert a NULL state field or single-valued object field value into the respective TRUE or FALSE value.

  • Boolean operators use three valued logic, defined by Table 1, Table 2, and Table 3.

Table 1. Definition of the AND Operator
AND T F U

T

T

F

U

F

F

F

F

U

U

F

U

Table 2. Definition of the OR Operator
OR T F U

T

T

T

T

F

T

F

U

U

T

U

U

Table 3. Definition of the NOT Operator
NOT

T

F

F

T

U

U

The Jakarta Persistence query language defines the empty string, '', as a string with length zero, which is not equal to a NULL value. However, NULL values and empty strings may not always be distinguished when queries are mapped to some databases. Application developers should therefore not rely on the semantics of query comparisons involving the empty string and NULL value.

4.6.14. Equality and Comparison Semantics

Only the values of like types are permitted to be compared. A type is like another type if they correspond to the same Java language type, or if one is a primitive Java language type and the other is the wrapped Java class type equivalent (e.g., int and Integer are like types in this sense). There is one exception to this rule: it is valid to compare numeric values for which the rules of numeric promotion apply. Conditional expressions attempting to compare non-like type values are disallowed except for this numeric case.

Note that the arithmetic operators, the string concatenation operator, and comparison operators are permitted to be applied to state fields and input parameters of the wrapped Java class equivalents to the primitive numeric Java types.

Two entities of the same abstract schema type are equal if and only if they have the same primary key value.

Only equality/inequality comparisons over enums are required to be supported.

Comparisons over instances of embeddable class or map entry types are not supported.

The following examples illustrate the syntax and semantics of the Jakarta Persistence query language. These examples are based on the example presented in Section 4.3.2.

Find all orders:

SELECT o
FROM Order o

Find all orders that need to be shipped to California:

SELECT o
FROM Order o
WHERE o.shippingAddress.state = 'CA'

Find all states for which there are orders:

SELECT DISTINCT o.shippingAddress.state
FROM Order o

Find all orders that have line items:

SELECT DISTINCT o
FROM Order o JOIN o.lineItems l

Note that the result of this query does not include orders with no associated line items. This query can also be written as:

SELECT o
FROM Order o
WHERE o.lineItems IS NOT EMPTY

Find all orders that have no line items:

SELECT o
FROM Order o
WHERE o.lineItems IS EMPTY

Find all pending orders:

SELECT DISTINCT o
FROM Order o JOIN o.lineItems l
WHERE l.shipped = FALSE

Find all orders in which the shipping address differs from the billing address. This example assumes that the application developer uses two distinct entity types to designate shipping and billing addresses.

SELECT o
FROM Order o
WHERE
    NOT (o.shippingAddress.state = o.billingAddress.state AND
         o.shippingAddress.city = o.billingAddress.city AND
         o.shippingAddress.street = o.billingAddress.street)

If the application developer uses a single entity type in two different relationships for both the shipping address and the billing address, the above expression can be simplified based on the equality rules defined in Section 4.6.14. The query can then be written as:

SELECT o
FROM Order o
WHERE o.shippingAddress <> o.billingAddress

The query checks whether the same entity abstract schema type instance (identified by its primary key) is related to an order through two distinct relationships.

4.6.14.1. Queries Using Input Parameters

The following query finds the orders for a product whose name is designated by an input parameter:

SELECT DISTINCT o
FROM Order o JOIN o.lineItems l
WHERE l.product.name = ?1

For this query, the input parameter must be of the type of the state field name, i.e., a string.

4.7. Scalar Expressions

Numeric, string, datetime, case, and entity type expressions result in scalar values.

Scalar expressions may be used in the SELECT clause of a query as well as in the WHERE [74] and HAVING clauses.

scalar_expression ::=
    arithmetic_expression |
    string_expression |
    enum_expression |
    datetime_expression |
    boolean_expression |
    case_expression |
    entity_type_expression |
    entity_id_or_version_function

4.7.1. Literals

A string literal is enclosed in single quotes—for example: 'literal'. A string literal that includes a single quote is represented by two single quotes—for example: 'literal''s'. String literals in queries, like Java String literals, use unicode character encoding. The use of Java escape notation is not supported in query string literals.

A numeric literal may be either:

  • a decimal Java integer (int or long) literal

  • a Java floating point (float or double) literal, or

  • a literal BigInteger or BigDecimal.

A suffix L, D, or F may be used to indicate the specific numeric type, in accordance with the Java Language Specification. The suffix is not case-sensitive. The literal numeric value preceding the suffix must conform to the rules for Java numeric literals established by the Java Language Specification.

A suffix BI or BD may be used to indicate a literal BigInteger or BigDecimal, respectively. The literal numeric value preceding the suffix must be an exact or approximate SQL numeric literal. For a BigInteger literal, the numeric value must be an exact integer literal.

Just as in Java, when a numeric literal has no suffix:

  • an integer literal is interpreted as a Java int, and

  • a floating point literal is interpreted as a Java double.

Support for hexadecimal and octal numeric literals is not required by this specification.

Enum literals support the use of Java enum literal syntax. The fully qualified enum class name must be specified.

The JDBC escape syntax may be used for the specification of date, time, and timestamp literals. For example:

SELECT o
FROM Customer c JOIN c.orders o
WHERE c.name = 'Smith'
    AND o.submissionDate < {d '2008-12-31'}

The portability of this syntax for date, time, and timestamp literals is dependent upon the JDBC driver in use. Persistence providers are not required to translate from this syntax into the native syntax of the database or driver.

The boolean literals are TRUE and FALSE.

Entity type literals are specified by entity names—for example: Customer.

Although reserved literals appear in upper case, they are case-insensitive.

4.7.2. Identification Variables

All identification variables used in the WHERE or HAVING clause of a SELECT or DELETE statement must be declared in the FROM clause, as described in Section 4.4.2. The identification variables used in the WHERE clause of an UPDATE statement must be declared in the UPDATE clause.

Identification variables are existentially quantified in the WHERE and HAVING clause. This means that an identification variable represents a member of a collection or an instance of an entity’s abstract schema type. An identification variable never designates a collection in its entirety.

4.7.3. Path Expressions

It is illegal to use a collection_valued_path_expression within a WHERE or HAVING clause as part of a conditional expression except in an empty_collection_comparison_expression, in a collection_member_expression, or as an argument to the SIZE operator.

4.7.4. Input Parameters

An input parameter allows a value in the Java program to be safely interpolated into the text of the parameterized query.

In a given query, either positional or named parameters may be used. Positional and named parameters must not be mixed in a single query.

The persistence provider is required to support input parameters which occur in the WHERE clause or HAVING clause of a query, or as the new value for an update item in the SET clause of an update statement.

Note that if an input parameter value is null, comparison operations or arithmetic operations involving the input parameter will result in an unknown value. See Section 4.6.13.

An input parameter might be single-valued or collection-valued. An input parameter which occurs directly to the right of the IN keyword in an IN predicate, as defined in Section 4.6.5, is collection-valued. Every other input parameter is single-valued

The API for the binding concrete arguments to query parameters is described in Section 3.11.

4.7.4.1. Positional Parameters

The following rules apply to positional input parameters.

  • A positional parameter is designated by an integer, and prefixed with a ? symbol (question mark) in the text of the query string. For example: ?1.

  • Input parameters are numbered starting from 1.

  • A given positional parameter may occur more than once in the query string.

  • The ordering of the use of parameters within the text of the query string need not match the numbering of the positional parameters.

4.7.4.2. Named Parameters

A named parameter is denoted by an identifier, and prefixed by the : symbol (colon) in the text of the query string. The identifier name must follow the usual rules for identifiers specified in Section 4.4.1. Named parameters are case-sensitive.

Example:

SELECT c
FROM Customer c
WHERE c.status = :stat

A given named parameter may occur more than once in the query string.

4.7.5. Arithmetic Expressions

The arithmetic operators are:

  • +, - unary

  • *, / multiplication and division

  • +, - addition and subtraction

Arithmetic operations use numeric promotion.

Arithmetic functions are described in Section 4.7.7.2.

4.7.6. String concatenation operator

The binary concatenation operator is ||. Its operands must be string expressions.

4.7.7. Built-in String, Arithmetic, and Datetime Functional Expressions

The Jakarta Persistence query language includes the built-in functions described in Section 4.7.7.1, Section 4.7.7.2, Section 4.7.7.3, which may be used in the SELECT, WHERE or HAVING clause of a query. The invocation of predefined database functions and user-defined database functions is described in Section 4.7.9.

If the value of any argument to a functional expression is null or unknown, the value of the functional expression is unknown.

4.7.7.1. String Functions
functions_returning_strings ::=
    CONCAT(string_expression, string_expression {, string_expression}*) |
    SUBSTRING(string_expression,
              arithmetic_expression [, arithmetic_expression]) |
    TRIM([[trim_specification] [trim_character] FROM] string_expression) |
    LOWER(string_expression) |
    UPPER(string_expression) |
    REPLACE(string_expression, string_expression, string_expression) |
    LEFT(string_expression, arithmetic_expression) |
    RIGHT(string_expression, arithmetic_expression)
trim_specification ::= LEADING | TRAILING | BOTH

functions_returning_numerics ::=
    LENGTH(string_expression) |
    LOCATE(string_expression, string_expression[, arithmetic_expression])

The CONCAT function returns a string that is a concatenation of its arguments.

The second and third arguments of the SUBSTRING function denote the starting position and length of the substring to be returned. These arguments are integers. The third argument is optional. If it is not specified, the substring from the start position to the end of the string is returned. The first position of a string is denoted by 1. The SUBSTRING function returns a string.

The TRIM function trims the specified character from a string. If the character to be trimmed is not specified, it will be assumed to be space (or blank). The optional trim_character is a single-character string literal or a character-valued input parameter (i.e., char or Character) [75]. If a trim specification is not provided, it defaults to BOTH. The TRIM function returns the trimmed string.

The LOWER and UPPER functions convert a string to lower and upper case, respectively, with regard to the locale of the database. They return a string.

The LEFT and RIGHT functions return the leftmost or rightmost substring, respectively, of the first argument whose length is given by the second argument.

The REPLACE function replaces all occurrences within the first argument string of the second argument string with the third argument string.

The LOCATE function returns the position at which one string occurs within a second string, optionally ignoring any occurrences that begin before a specified character position in the second string. It returns the first character position within the second string (after the specified character position, if any) at which the first string occurs, as an integer, where the first character of the second string is denoted by 1. That is, the first argument is the string to be searched for; the second argument is the string to be searched in; the optional third argument is an integer representing the character position at which the search starts (by default, 1, the first character of the second string). If the first string does not occur within the second string, 0 is returned.[76]

The LENGTH function returns the length of the string in characters as an integer.

4.7.7.2. Arithmetic Functions
functions_returning_numerics ::=
    ABS(arithmetic_expression) |
    CEILING(arithmetic_expression) |
    EXP(arithmetic_expression) |
    FLOOR(arithmetic_expression) |
    LN(arithmetic_expression) |
    MOD(arithmetic_expression, arithmetic_expression) |
    POWER(arithmetic_expression, arithmetic_expression) |
    ROUND(arithmetic_expression, arithmetic_expression) |
    SIGN(arithmetic_expression) |
    SQRT(arithmetic_expression) |
    SIZE(collection_valued_path_expression) |
    INDEX(identification_variable) |
    extract_datetime_field

The ABS, CEILING, and FLOOR functions accept a numeric argument and return a number (integer, float, or double) of the same type as the argument.

The SIGN function accepts a numeric argument and returns an integer.

The SQRT, EXP, and LN functions accept a numeric argument and return a double.

The MOD function accepts two integer arguments and returns an integer.

The ROUND function accepts a numeric argument and an integer argument and returns a number of the same type as the first argument.

The POWER function accepts two numeric arguments and returns a double.

Numeric arguments to these functions may correspond to the numeric Java object types as well as the primitive numeric types.

The SIZE function returns an integer value, the number of elements of the collection. If the collection is empty, the SIZE function evaluates to zero.

The INDEX function returns an integer value corresponding to the position of its argument in an ordered list. The INDEX function can only be applied to identification variables denoting types for which an order column has been specified.

In the following example, studentWaitlist is a list of students for which an order column has been specified:

SELECT w.name
FROM Course c JOIN c.studentWaitlist w
WHERE c.name = 'Calculus'
AND INDEX(w) = 0
4.7.7.3. Datetime Functions
functions_returning_datetime :=
    CURRENT_DATE |
    CURRENT_TIME |
    CURRENT_TIMESTAMP |
    LOCAL DATE |
    LOCAL TIME |
    LOCAL DATETIME |
    extract_datetime_part

The functions LOCAL DATE, LOCAL TIME, and LOCAL DATETIME return the value of the current date, time, or timestamp on the database server, respectively. Their types are java.time.LocalDate, java.time.LocalTime, and java.time.LocalDateTime respectively.

The functions CURRENT_DATE, CURRENT_TIME, and CURRENT_TIMESTAMP return the value of the current date, time, or timestamp on the database server, respectively. Their types are java.sql.Date, java.sql.Time, and java.sql.Timestamp respectively.

The EXTRACT function takes a datetime argument and one of the following field type identifiers: YEAR, QUARTER, MONTH, WEEK, DAY, HOUR, MINUTE, SECOND, DATE, TIME.

EXTRACT returns the value of the corresponding field or part of the datetime.

extract_datetime_field :=
    EXTRACT(datetime_field FROM datetime_expression)

datetime_field := identification_variable

For the following field type identifiers, EXTRACT returns an integer value:

  • YEAR means the calendar year.

  • QUARTER means the calendar quarter, numbered from 1 to 4.

  • MONTH means the calendar month of the year, numbered from 1.

  • WEEK means the ISO-8601 week number.

  • DAY means the calendar day of the month, numbered from 1.

  • HOUR means the hour of the day in 24-hour time, numbered from 0 to 23.

  • MINUTE means the minute of the hour, numbered from 0 to 59.

For the SECOND field type identifier, EXTRACT returns a floating point value:

  • SECOND means the second of the minute, numbered from 0 to 59, including a fractional part representing fractions of a second.

It is illegal to pass a datetime argument which does not have the given field type to EXTRACT.

extract_datetime_part :=
    EXTRACT(datetime_part FROM datetime_expression)

datetime_part := identification_variable

For the following field type identifiers, EXTRACT returns a part of the datetime value:

  • DATE means the date part of a datetime.

  • TIME means the time part of a datetime.

It is illegal to pass a datetime argument which does not have the given part to EXTRACT.

FROM Course c WHERE c.year = EXTRACT(YEAR FROM LOCAL DATE)

4.7.8. Typecasts

The CAST function converts an expression of one type to an expression of a different type.

string_cast_function::=
    CAST(scalar_expression AS STRING)
arithmetic_cast_function::=
    CAST(string_expression AS {INTEGER | LONG | FLOAT | DOUBLE})

The persistence provider is required to accept typecasts of the following forms:

  • any scalar expression to STRING

  • any string expression to INTEGER, LONG, FLOAT, or DOUBLE

Typecast expressions are evaluated by the database, with semantics that vary somewhat between different databases.

When a typecast occurs as a select expression, the result type of the select expression is:

  • java.lang.String for a cast to STRING

  • java.lang.Integer, java.lang.Long, java.lang.Float, or java.lang.Double for a cast to INTEGER, LONG, FLOAT, or DOUBLE, respectively

4.7.9. Invocation of Predefined and User-defined Database Functions

The invocation of functions other than the built-in functions of the Jakarta Persistence query language is supported by means of the function_invocation syntax. This includes the invocation of predefined database functions and user-defined database functions.

function_invocation ::= FUNCTION(function_name {, function_arg}*)

function_arg ::=
    literal |
    state_valued_path_expression |
    input_parameter |
    scalar_expression

The function_name argument is a string that denotes the database function that is to be invoked. The arguments must be suitable for the database function that is to be invoked. The result of the function must be suitable for the invocation context.

The function may be a database-defined function or a user-defined function. The function may be a scalar function or an aggregate function.

Applications that use the function_invocation syntax will not be portable across databases.

Example:

SELECT c
FROM Customer c
WHERE FUNCTION('hasGoodCredit', c.balance, c.creditLimit)

4.7.10. Case Expressions

The following forms of case expressions are supported: general case expressions, simple case expressions, coalesce expressions, and nullif expressions.[77]

case_expression ::=
    general_case_expression |
    simple_case_expression |
    coalesce_expression |
    nullif_expression

general_case_expression ::=
    CASE when_clause {when_clause}* ELSE scalar_expression END
when_clause ::= WHEN conditional_expression THEN scalar_expression

simple_case_expression ::=
    CASE case_operand simple_when_clause {simple_when_clause}*
    ELSE scalar_expression
    END
case_operand ::= state_valued_path_expression | type_discriminator
simple_when_clause ::= WHEN scalar_expression THEN scalar_expression

coalesce_expression ::= COALESCE(scalar_expression {, scalar_expression}+)

nullif_expression ::= NULLIF(scalar_expression, scalar_expression)

Examples:

UPDATE Employee e
SET e.salary =
    CASE WHEN e.rating = 1 THEN e.salary * 1.1
         WHEN e.rating = 2 THEN e.salary * 1.05
         ELSE e.salary * 1.01
    END

UPDATE Employee e
SET e.salary =
    CASE e.rating WHEN 1 THEN e.salary * 1.1
                  WHEN 2 THEN e.salary * 1.05
                  ELSE e.salary * 1.01
    END

SELECT e.name,
    CASE TYPE(e) WHEN Exempt THEN 'Exempt'
                 WHEN Contractor THEN 'Contractor'
                 WHEN Intern THEN 'Intern'
                 ELSE 'NonExempt'
    END
FROM Employee e
WHERE e.dept.name = 'Engineering'

SELECT e.name,
       f.name,
       CONCAT(CASE WHEN f.annualMiles > 50000 THEN 'Platinum '
                   WHEN f.annualMiles > 25000 THEN 'Gold '
                   ELSE ''
              END,
       'Frequent Flyer')
FROM Employee e JOIN e.frequentFlierPlan f

4.7.11. Identifier and Version Functions

The ID and VERSION functions evaluate to the primary key or version, respectively, of their argument, which must be an identification variable assigned an entity abstract schema type or a path expression resolving to a one-to-one or many-to-one relationship field. For example, if Person has a primary key field named ssn, then ID(person) is a synonym for person.ssn.

entity_id_or_version_function ::= id_function | version_function
id_function ::=
    ID(general_identification_variable |
       single_valued_object_path_expression)
version_function ::=
    VERSION(general_identification_variable |
            single_valued_object_path_expression)

The result type of an ID or VERSION function expression is the primary key type or version type of the argument entity, respectively.

The result may be compared to an input parameter:

DELETE from Employee
WHERE id(this) = :id
  AND version(this) = :version

A persistence provider is not required to support the use of the ID function for entities with composite primary keys.

4.7.12. Entity Type Expressions and Literal Entity Types

An entity type expression can be used to restrict query polymorphism. The syntax of an entity type expression is as follows:

entity_type_expression ::=
    type_discriminator |
    entity_type_literal |
    input_parameter
type_discriminator ::=
    TYPE(general_identification_variable |
         single_valued_object_path_expression |
         input_parameter)

The TYPE operator returns the exact type of its argument, which must be an identification variable assigned an entity abstract schema type, a path expression resolving to a one-to-one or many-to-one relationship field, or an input parameter.

An entity_type_literal specifies a literal entity type by its entity name defined above in Section 4.3.1.

For an input parameter, the entity type must be specified by calling Query.setParameter() with the java.lang.Class object representing the entity class.

Examples:

SELECT e
FROM Employee e
WHERE TYPE(e) IN (Exempt, Contractor)

SELECT e
FROM Employee e
WHERE TYPE(e) IN (:empType1, :empType2)

SELECT e
FROM Employee e
WHERE TYPE(e) IN :empTypes

SELECT TYPE(e)
FROM Employee e
WHERE TYPE(e) <> Exempt

4.7.13. Numeric Expressions and Type Promotion

Every numeric expression in a query is assigned a Java numeric type according to the following rules:

  • An expression that corresponds to a persistent state field is of the same type as that persistent state field.

  • An expression that corresponds to one of arithmetic functions described in Section 4.7.7.2 is of the type defined by Section 4.7.7.2.

  • An expression that corresponds to one of an aggregate functions described in Section 4.9.5 is of the type defined by Section 4.9.5.

For a CASE expression, COALESCE expression, NULLIF expression, or arithmetic operator expression (+, -, *, /), the numeric type is determined by its operand types, and by the following rules[78].

  • If there is an operand of type Double or double, the expression is of type Double;

  • otherwise, if there is an operand of type Float or float, the expression is of type Float;

  • otherwise, if there is an operand of type BigDecimal, the expression is of type BigDecimal;

  • otherwise, if there is an operand of type BigInteger, the expression is of type BigInteger, unless the operator is / (division), in which case the expression type is not defined here;

  • otherwise, if there is an operand of type Long or long, the expression is of type Long, unless the operator is / (division), in which case the expression type is not defined here;

  • otherwise, if there is an operand of integral type, the expression is of type Integer, unless the operator is / (division), in which case the expression type is not defined here.

Users should note that the semantics of the SQL division operation are not standard across databases. In particular, when both operands are of integral types, the result of the division operation will be an integral type in some databases, and an non-integral type in others. Portable applications should not assume a particular result type.

For numeric expressions occurring in the SELECT clause, these rules determine the Java object type returned in the query result list.

4.8. GROUP BY, HAVING

The GROUP BY construct enables the aggregation of result values according to a set of properties. The HAVING construct enables conditions to be specified that further restrict the query result. Such conditions are restrictions upon the groups.

The syntax of the GROUP BY and HAVING clauses is as follows:

groupby_clause ::= GROUP BY groupby_item {, groupby_item}*
groupby_item ::= single_valued_path_expression | identification_variable

having_clause ::= HAVING conditional_expression

If a query contains both a WHERE clause and a GROUP BY clause, the effect is that of first applying the where clause, and then forming the groups and filtering them according to the HAVING clause. The HAVING clause causes those groups to be retained that satisfy the condition of the HAVING clause.

The requirements for the SELECT clause when GROUP BY is used follow those of SQL: namely, any item that appears in the SELECT clause (other than as an aggregate function or as an argument to an aggregate function) must also appear in the GROUP BY clause. In forming the groups, null values are treated as the same for grouping purposes.

Grouping by an entity is permitted. In this case, the entity must contain no serialized state fields or lob-valued state fields that are eagerly fetched. Grouping by an entity that contains serialized state fields or lob-valued state fields is not portable, since the implementation is permitted to eagerly fetch fields or properties that have been specified as LAZY.

Grouping by embeddables is not supported.

The HAVING clause is used to filter over the groups, and can contain aggregate functions over attributes included in the groups and/or functions or other query language operators over the attributes that are used for grouping. It is not required that an aggregate function used in the HAVING clause also be used in the SELECT clause.

If there is no GROUP BY clause and the HAVING clause is used, the result is treated as a single group, and the select list can only consist of aggregate functions. The use of HAVING in the absence of GROUP BY is not required to be supported by an implementation of this specification. Portable applications should not rely on HAVING without the use of GROUP BY.

Examples:

SELECT c.status, AVG(c.filledOrderCount), COUNT(c)
FROM Customer c
GROUP BY c.status
HAVING c.status IN (1, 2)

SELECT c.country, COUNT(c)
FROM Customer c
GROUP BY c.country
HAVING COUNT(c) > 30

SELECT c, COUNT(o)
FROM Customer c JOIN c.orders o
GROUP BY c
HAVING COUNT(o) >= 5

4.9. SELECT Clause

The SELECT clause specifies the query result, as a list of items to be returned by the query.

The SELECT clause can contain one or more of the following elements:

  • an identification variable that ranges over an abstract schema type,

  • a single-valued path expression,

  • a scalar expression,

  • an aggregate expression,

  • a constructor expression.

The SELECT clause has the following syntax:

select_clause ::= SELECT [DISTINCT] select_item {, select_item}*
select_item ::= select_expression [[AS] result_variable]
select_expression ::=
    single_valued_path_expression |
    scalar_expression |
    aggregate_expression |
    identification_variable |
    OBJECT(identification_variable) |
    constructor_expression
constructor_expression ::=
    NEW constructor_name (constructor_item {, constructor_item}*)
constructor_item ::=
    single_valued_path_expression |
    scalar_expression |
    aggregate_expression |
    identification_variable
aggregate_expression ::=
    {AVG | MAX | MIN | SUM} ([DISTINCT] state_valued_path_expression) |
     COUNT ([DISTINCT] identification_variable | state_valued_path_expression |
         single_valued_object_path_expression) |
     function_invocation

For example:

SELECT c.id, c.status
FROM Customer c JOIN c.orders o
WHERE o.count > 100

In the following example, videoInventory is a Map from the entity Movie to the number of copies in stock:

SELECT v.location.street, KEY(i).title, VALUE(i)
FROM VideoStore v JOIN v.videoInventory i
WHERE v.location.zipcode = '94301' AND VALUE(i) > 0

Note that the SELECT clause must be specified to return only single-valued expressions. The query below is therefore not valid:

SELECT o.lineItems FROM Order AS o

The DISTINCT keyword is used to specify that duplicate values must be eliminated from the query result.

If DISTINCT is not specified, duplicate values are not eliminated.

The result of DISTINCT over embeddable objects or map entry results is undefined.

Standalone identification variables in the SELECT clause may optionally be qualified by the OBJECT operator.[79] The SELECT clause must not use the OBJECT operator to qualify path expressions.

A result_variable assigns a name to a select_item in the query result. The result variable must be a valid identifier, as defined in Section 4.4.1, must not be a reserved identifier, and must not collide with any identification variable declared in the FROM clause. A result variable may be used to refer to an element of the select clause from an item in the ORDER BY clause, as specified in Section 4.10. Like identification variables, result variables are case-insensitive.

Example:

SELECT c, COUNT(l) AS itemCount
FROM Customer c JOIN c.orders o JOIN o.lineItems l
WHERE c.address.state = 'CA'
GROUP BY c
ORDER BY itemCount

The SELECT clause is optional. A query with a missing SELECT clause is interpreted as if it had the following single-item SELECT clause: select this, where this is the implicit identification variable.

Thus, the following queries are equivalent:

FROM Order
WHERE customer.lastname = 'Smith'
  AND customer.firstname= 'John'
SELECT this
FROM Order
WHERE this.customer.lastname = 'Smith'
  AND this.customer.firstname= 'John'
SELECT ord
FROM Order AS ord
WHERE ord.customer.lastname = 'Smith'
  AND ord.customer.firstname= 'John'

If the implicit identification variable has not been assigned an abstract schema type, the SELECT clause is required.

4.9.1. Result Type of the SELECT Clause

The type of the query result specified by the SELECT clause of a query is an entity abstract schema type, a state field type, the result of a scalar expression, the result of an aggregate function, the result of a construction operation, or some sequence of these.

The result type of the SELECT clause is defined by the result types of the select expressions contained in it. When multiple select expressions are used in the SELECT clause, the elements in this result correspond in order to the order of their specification in the SELECT clause and in type to the result types of each of the select expressions.

The type of the result of a select_expression is as follows:

  • The result type of an identification_variable is the type of the entity object or embeddable object to which the identification variable corresponds. The type of an identification_variable that refers to an entity abstract schema type is the type of the entity to which that identification variable corresponds or a subtype as determined by the object/relational mapping.

  • The result type of a single_valued_path_expression that is a state_field_path_expression is the same type as the corresponding state field of the entity or embeddable class. If the state field of the entity is a primitive type, the result type is the corresponding object type.

  • The result type of a single_valued_path_expression that is a single_valued_object_path_expression is the type of the entity object or embeddable object to which the path expression corresponds. A single_valued_object_path_expression that results in an entity object will result in an entity of the type of the relationship field or the subtype of the relationship field of the entity object as determined by the object/relational mapping.

  • The result type of a single_valued_path_expression that is an identification_variable to which the KEY or VALUE function has been applied is determined by the type of the map key or value respectively, as defined by the above rules.

  • The result type of a single_valued_path_expression that is an identification_variable to which the ENTRY function has been applied is java.util.Map.Entry, where the key and value types of the map entry are determined by the above rules as applied to the map key and map value respectively.

  • The result type of a scalar_expression is the type of the scalar value to which the expression evaluates. The result type of a numeric scalar_expression is defined in Section 4.7.13.

  • The result type of an entity_type_expression scalar expression is the Java class to which the resulting abstract schema type corresponds.

  • The result type of aggregate_expression is defined in Section 4.9.5.

  • The result type of a constructor_expression is the type of the class for which the constructor is defined. The types of the arguments to the constructor are defined by the above rules.

4.9.2. Constructor Expressions in the SELECT Clause

A constructor may be used in the SELECT list to return an instance of a Java class. The specified class is not required to be an entity or to be mapped to the database. The constructor name must be fully qualified.

If an entity class name is specified as the constructor name in the SELECT NEW clause, the resulting entity instances will be in either the new or the detached state, depending on whether a primary key is retrieved for the constructed object.

If a single_valued_path_expression or identification_variable that is an argument to the constructor references an entity, the resulting entity instance referenced by that single_valued_path_expression or identification_variable will be in the managed state.

For example,

SELECT NEW com.acme.example.CustomerDetails(c.id, c.status, o.count)
FROM Customer c JOIN c.orders o
WHERE o.count > 100

4.9.3. Null Values in the Query Result

If the result of a query corresponds to an association field or state field whose value is null, that null value is returned in the result of the query method. The IS NOT NULL construct can be used to eliminate such null values from the result set of the query.

Note, however, that state field types defined in terms of Java numeric primitive types cannot produce NULL values in the query result. A query that returns such a state field type as a result type must not return a null value.

4.9.4. Embeddables in the Query Result

If the result of a query corresponds to an identification variable or state field whose value is an embeddable, the embeddable instance returned by the query will not be in the managed state (i.e., it will not be part of the state of any managed entity).

In the following example, the Address instances returned by the query will reference Phone instances. While the Phone instances will be managed, the Address instances referenced by the addr result variable will not be. Modifications to these embeddable instances will have no effect on persistent state.

@Entity
public class Employee {
    @Id
    int id;

    Address address;

    // ...
}

@Embeddable
public class Address {
    String street;

    // ...

    @OneToOne
    Phone phone; // fetch=EAGER
}

@Entity
public class Phone {
    @Id
    int id;

    // ...

    @OneToOne(mappedBy="address.phone")
    Employee emp; // fetch=EAGER
}
SELECT e.address AS addr
FROM Employee e

4.9.5. Aggregate Functions in the SELECT Clause

The result of a query may be the result of an aggregate function applied to a path expression.

The following aggregate functions can be used in the SELECT clause of a query: AVG, COUNT, MAX, MIN, SUM, aggregate functions defined in the database.

For all aggregate functions except COUNT, the path expression that is the argument to the aggregate function must terminate in a state field. The path expression argument to COUNT may terminate in either a state field or a association field, or the argument to COUNT may be an identification variable.

Arguments to the functions SUM and AVG must be numeric. Arguments to the functions MAX and MIN must correspond to orderable state field types (i.e., numeric types, string types, character types, or date types).

The Java type that is contained in the result of a query using an aggregate function is as follows:

  • COUNT returns Long.

  • MAX, MIN return the type of the state field to which they are applied.

  • AVG returns Double.

  • SUM returns Long when applied to state fields of integral types (other than BigInteger); Double when applied to state fields of floating point types; BigInteger when applied to state fields of type BigInteger; and BigDecimal when applied to state fields of type BigDecimal.

Null values are eliminated before the aggregate function is applied, regardless of whether the keyword DISTINCT is specified.

If SUM, AVG, MAX, or MIN is used, and there are no values to which the aggregate function can be applied, the result of the aggregate function is NULL.

If COUNT is used, and there are no values to which COUNT can be applied, the result of the aggregate function is 0.

The argument to an aggregate function may be preceded by the keyword DISTINCT to specify that duplicate values are to be eliminated before the aggregate function is applied.[80]

The use of DISTINCT with COUNT is not supported for arguments of embeddable types or map entry types.

The invocation of aggregate database functions, including user defined functions, is supported by means of the FUNCTION operator. See Section 4.7.9.

The following query returns the average order quantity:

SELECT AVG(o.quantity) FROM Order o

The following query returns the total cost of the items that John Smith has ordered.

SELECT SUM(l.price)
FROM Order o JOIN o.lineItems l JOIN o.customer c
WHERE c.lastname = 'Smith' AND c.firstname = 'John'

The following query returns the total number of orders.

SELECT COUNT(o) FROM Order o

The following query counts the number of items in John Smith’s order for which prices have been specified.

SELECT COUNT(l.price)
FROM Order o JOIN o.lineItems l JOIN o.customer c
WHERE c.lastname = 'Smith' AND c.firstname = 'John'

Note that this is equivalent to:

SELECT COUNT(l)
FROM Order o JOIN o.lineItems l JOIN o.customer c
WHERE c.lastname = 'Smith' AND c.firstname = 'John' AND l.price IS NOT NULL

4.10. ORDER BY Clause

The ORDER BY clause specifies how the results of a query should be sorted. The syntax of the ORDER BY clause is:

orderby_clause ::= ORDER BY orderby_item {, orderby_item}*
orderby_item ::= orderby_expression [ASC | DESC] [NULLS {FIRST | LAST}]
orderby_expression ::=
    state_field_path_expression |
    general_identification_variable |
    result_variable |
    scalar_expression

The ORDER BY clause specifies a list of items. Each orderby_expression must be one of the following:

  1. A state_field_path_expression evaluating to an orderable state field of an entity or embeddable class abstract schema type designated in the SELECT clause by either:

    • a general_identification_variable, or

    • a single_valued_object_path_expression.

  2. A state_field_path_expression evaluating to the same state field of the same entity or embeddable abstract schema type as a state_field_path_expression in the SELECT clause.

  3. A general_identification_variable evaluating to the same map field of the same entity or embeddable abstract schema type as a general_identification_variable in the SELECT clause.

  4. A reference to a result_variable declared by an orderable item in the SELECT clause. The orderable item must be an aggregate_expression, a scalar_expression, or a state_field_path_expression.

  5. Any scalar_expression involving only state_field_path_expressions which would be allowed according to items 1 or 2 above.

Depending on the database, arbitrary scalar expressions may not be allowed in the ORDER BY clause. Therefore, applications which require portability between databases should not depend on the use of a scalar expression in ORDER BY if it is only permitted by item 5.

For example, the four queries below are legal.

SELECT o
FROM Customer c JOIN c.orders o JOIN c.address a
WHERE a.state = 'CA'
ORDER BY o.quantity DESC, o.totalcost

SELECT o.quantity, a.zipcode
FROM Customer c JOIN c.orders o JOIN c.address a
WHERE a.state = 'CA'
ORDER BY o.quantity, a.zipcode

SELECT o.quantity, o.cost*1.08 AS taxedCost, a.zipcode
FROM Customer c JOIN c.orders o JOIN c.address a
WHERE a.state = 'CA' AND a.county = 'Santa Clara'
ORDER BY o.quantity, taxedCost, a.zipcode

SELECT AVG(o.quantity) as q, a.zipcode
FROM Customer c JOIN c.orders o JOIN c.address a
WHERE a.state = 'CA'
GROUP BY a.zipcode
ORDER BY q DESC

The following query is legal, but might not be supported on every database.

SELECT c, o
FROM Customer c JOIN c.orders o JOIN c.address a
WHERE a.state = 'CA'
ORDER BY UPPER(c.lastname), UPPER(c.firstname)

The following two queries are not legal because the orderby_item is not reflected in the SELECT clause of the query.

SELECT p.product_name
FROM Order o JOIN o.lineItems l JOIN l.product p JOIN o.customer c
WHERE c.lastname = 'Smith' AND c.firstname = 'John'
ORDER BY p.price

SELECT p.product_name
FROM Order o, IN(o.lineItems) l JOIN o.customer c
WHERE c.lastname = 'Smith' AND c.firstname = 'John'
ORDER BY o.quantity

The keyword ASC specifies that ascending ordering is used for the associated orderby_item; the keyword DESC specifies that descending ordering is used. If neither keyword is explicitly specified, ascending ordering is the default.

The interpretation of ascending or descending order is determined by the database, but, in general:

  • ascending order for numeric values means smaller values first, while descending order means larger values first, and

  • strings are sorted lexicographically, using a database-dependent collation.

The keyword NULLS specifies the ordering of null values, either FIRST or LAST.

  • FIRST means that results are sorted so that all null values occur before all non-null values.

  • LAST means that results are sorted so that all null values occur after all non-null values.

If NULLS is not specified, the database determines whether null values occur first or last.

Items occurring earlier in the ORDER BY clause take precedence. That is, an item occurring later in the ORDER BY clause is only used to resolve "ties" between results which cannot be unambiguously ordered using only earlier items.

The order of query results must be preserved in the result list or stream returned by a query execution method when an ORDER BY clause is specified.

4.11. Bulk Update and Delete Operations

Bulk update and delete operations apply to entities of a single entity class (together with its subclasses, if any). Only one entity abstract schema type may be specified in the FROM or UPDATE clause.

The syntax of these operations is as follows:

update_statement ::= update_clause [where_clause]
update_clause ::= UPDATE entity_name [[AS] identification_variable]
                  SET update_item {, update_item}*
update_item ::= [identification_variable.]{single_valued_embeddable_object_field.}*
    {state_field | single_valued_object_field} = new_value
new_value ::=
    scalar_expression |
    simple_entity_expression |
    NULL

delete_statement ::= delete_clause [where_clause]
delete_clause ::= DELETE FROM entity_name [[AS] identification_variable]

The syntax of the WHERE clause is described in Section 4.5.

A delete operation only applies to entities of the specified class and its subclasses. It does not cascade to related entities.

The new_value specified for an update operation must be compatible in type with the field to which it is assigned.

Bulk update maps directly to a database update operation, bypassing optimistic locking checks. Portable applications must manually update the value of the version column, if desired, and/or manually validate the value of the version column.

The persistence context is not synchronized with the result of the bulk update or delete.

Caution should be used when executing bulk update or delete operations because they may result in inconsistencies between the database and the entities in the active persistence context. In general, bulk update and delete operations should only be performed within a transaction in a new persistence context or before fetching or accessing entities whose state might be affected by such operations._

Examples:

DELETE
FROM Customer c
WHERE c.status = 'inactive'

DELETE
FROM Customer c
WHERE c.status = 'inactive'
    AND c.orders IS EMPTY

UPDATE Customer c
SET c.status = 'outstanding'
WHERE c.balance < 10000

UPDATE Employee e
SET e.address.building = 22
WHERE e.address.building = 14
    AND e.address.city = 'Santa Clara'
    AND e.project = 'Jakarta EE'

4.12. BNF

BNF notation summary:

  • { …​ } grouping

  • [ …​ ] optional constructs

  • * zero or more

  • + one or more

  • | alternates

The following is the BNF for the Jakarta Persistence query language.

QL_statement ::= select_statement | update_statement | delete_statement
select_statement ::= union
union ::= intersection | union {UNION [ALL] | EXCEPT [ALL]} intersection
intersection ::= query_expression | intersection INTERSECT [ALL] query_expression
query_expression ::= select_query | (union)
select_query ::= [select_clause] from_clause [where_clause] [groupby_clause]
    [having_clause] [orderby_clause]
update_statement ::= update_clause [where_clause]
delete_statement ::= delete_clause [where_clause]
from_clause ::=
    FROM {this_implicit_variable | identification_variable_declarations}
this_implicit_variable ::= entity_name
identification_variable_declarations ::=
    identification_variable_declaration
    {, {identification_variable_declaration | collection_member_declaration}}*
identification_variable_declaration ::= range_variable_declaration {join | fetch_join}*
range_variable_declaration ::= entity_name [AS] identification_variable
join ::= range_join | path_join
range_join ::= join_spec range_variable_declaration [join_condition]
path_join ::=
    join_spec join_association_path_expression [AS] identification_variable [join_condition]
fetch_join ::= join_spec FETCH join_association_path_expression
join_spec ::= [INNER | LEFT [OUTER]] JOIN
join_condition ::= ON conditional_expression
join_association_path_expression ::=
    join_collection_valued_path_expression |
    join_single_valued_path_expression |
    TREAT(join_collection_valued_path_expression AS subtype) |
    TREAT(join_single_valued_path_expression AS subtype)
join_collection_valued_path_expression ::=
    [identification_variable.]{single_valued_embeddable_object_field.}* collection_valued_field
join_single_valued_path_expression ::=
    [identification_variable.]{single_valued_embeddable_object_field.}* single_valued_object_field
collection_member_declaration ::=
    IN (collection_valued_path_expression) [AS] identification_variable
qualified_identification_variable ::=
    map_field_identification_variable |
    ENTRY(identification_variable)
map_field_identification_variable ::=
    KEY(identification_variable) |
    VALUE(identification_variable)
single_valued_path_expression ::=
    qualified_identification_variable |
    TREAT(qualified_identification_variable AS subtype) |
    state_field_path_expression |
    single_valued_object_path_expression
general_identification_variable ::=
    identification_variable |
    map_field_identification_variable
general_subpath ::= simple_subpath | treated_subpath{.single_valued_object_field}*
simple_subpath ::=
    general_identification_variable |
    general_identification_variable{.single_valued_object_field}*
treated_subpath ::= TREAT(general_subpath AS subtype)
state_field_path_expression ::= [general_subpath.]state_field
state_valued_path_expression ::=
    state_field_path_expression | general_identification_variable
single_valued_object_path_expression ::=
    general_subpath.single_valued_object_field
collection_valued_path_expression ::= general_subpath.{collection_valued_field}
update_clause ::= UPDATE entity_name [[AS] identification_variable]
    SET update_item {, update_item}*
update_item ::= [identification_variable.]{single_valued_embeddable_object_field.}*
    {state_field | single_valued_object_field} = new_value
new_value ::=
    scalar_expression |
    simple_entity_expression |
    NULL
delete_clause ::= DELETE FROM entity_name [[AS] identification_variable]
select_clause ::= SELECT [DISTINCT] select_item {, select_item}*
select_item ::= select_expression [[AS] result_variable]
select_expression ::=
    single_valued_path_expression |
    scalar_expression |
    aggregate_expression |
    identification_variable |
    OBJECT(identification_variable) |
    constructor_expression
constructor_expression ::=
    NEW constructor_name (constructor_item {, constructor_item}*)
constructor_item ::=
    single_valued_path_expression |
    scalar_expression |
    aggregate_expression |
    identification_variable
aggregate_expression ::=
    {AVG | MAX | MIN | SUM} ([DISTINCT] state_valued_path_expression) |
    COUNT ([DISTINCT] identification_variable | state_valued_path_expression |
        single_valued_object_path_expression) |
    function_invocation
where_clause ::= WHERE conditional_expression
groupby_clause ::= GROUP BY groupby_item {, groupby_item}*
groupby_item ::= single_valued_path_expression | identification_variable
having_clause ::= HAVING conditional_expression
orderby_clause ::= ORDER BY orderby_item {, orderby_item}*
orderby_item ::= orderby_expression [ASC | DESC] [NULLS {FIRST | LAST}]
orderby_expression ::=
    state_field_path_expression |
    general_identification_variable |
    result_variable |
    scalar_expression
subquery ::= simple_select_clause subquery_from_clause [where_clause]
    [groupby_clause] [having_clause]
subquery_from_clause ::=
    FROM subselect_identification_variable_declaration
        {, subselect_identification_variable_declaration | collection_member_declaration}*
subselect_identification_variable_declaration ::=
    identification_variable_declaration |
    derived_path_expression [AS] identification_variable {join}* |
    derived_collection_member_declaration
derived_path_expression ::=
    general_derived_path.single_valued_object_field |
    general_derived_path.collection_valued_field
general_derived_path ::=
    simple_derived_path |
    treated_derived_path{.single_valued_object_field}*
simple_derived_path ::= superquery_identification_variable{.single_valued_object_field}*
treated_derived_path ::= TREAT(general_derived_path AS subtype)
derived_collection_member_declaration ::=
    IN superquery_identification_variable.{single_valued_object_field.}*collection_valued_field
simple_select_clause ::= SELECT [DISTINCT] simple_select_expression
simple_select_expression::=
    single_valued_path_expression |
    scalar_expression |
    aggregate_expression |
    identification_variable
scalar_expression ::=
    arithmetic_expression |
    string_expression |
    enum_expression |
    datetime_expression |
    boolean_expression |
    case_expression |
    entity_type_expression |
    entity_id_or_version_function
conditional_expression ::= conditional_term | conditional_expression OR conditional_term
conditional_term ::= conditional_factor | conditional_term AND conditional_factor
conditional_factor ::= [NOT] conditional_primary
conditional_primary ::= simple_cond_expression | (conditional_expression)
simple_cond_expression ::=
    comparison_expression |
    between_expression |
    in_expression |
    like_expression |
    null_comparison_expression |
    empty_collection_comparison_expression |
    collection_member_expression |
    exists_expression
between_expression ::=
    arithmetic_expression [NOT] BETWEEN
        arithmetic_expression AND arithmetic_expression |
    string_expression [NOT] BETWEEN string_expression AND string_expression |
    datetime_expression [NOT] BETWEEN datetime_expression AND datetime_expression
in_expression ::=
    {state_valued_path_expression | type_discriminator} [NOT] IN
        {(in_item{, in_item}*) | (subquery) | collection_valued_input_parameter}
in_item ::= literal | single_valued_input_parameter
like_expression ::=
    string_expression [NOT] LIKE pattern_value [ESCAPE escape_character]
null_comparison_expression ::=
    {single_valued_path_expression | input_parameter} IS [NOT] NULL
empty_collection_comparison_expression ::=
    collection_valued_path_expression IS [NOT] EMPTY
collection_member_expression ::= entity_or_value_expression
    [NOT] MEMBER [OF] collection_valued_path_expression
entity_or_value_expression ::=
    single_valued_object_path_expression |
    state_field_path_expression |
    simple_entity_or_value_expression
simple_entity_or_value_expression ::=
    identification_variable |
    input_parameter |
    literal
exists_expression ::= [NOT] EXISTS (subquery)
all_or_any_expression ::= {ALL | ANY | SOME} (subquery)
comparison_expression ::=
    string_expression comparison_operator {string_expression | all_or_any_expression} |
    boolean_expression {= | <>} {boolean_expression | all_or_any_expression} |
    enum_expression {= | <>} {enum_expression | all_or_any_expression} |
    datetime_expression comparison_operator
        {datetime_expression | all_or_any_expression} |
    entity_expression {= | <>} {entity_expression | all_or_any_expression} |
    arithmetic_expression comparison_operator {arithmetic_expression | all_or_any_expression} |
    entity_id_or_version_function {= | <>} input_parameter |
    entity_type_expression {= | <>} entity_type_expression}
comparison_operator ::= = | > | >= | < | <= | <>
arithmetic_expression ::=
    arithmetic_term | arithmetic_expression {+ | -} arithmetic_term
arithmetic_term ::= arithmetic_factor | arithmetic_term {* | /} arithmetic_factor
arithmetic_factor ::= [{+ | -}] arithmetic_primary
arithmetic_primary ::=
    state_valued_path_expression |
    numeric_literal |
    (arithmetic_expression) |
    input_parameter |
    functions_returning_numerics |
    aggregate_expression |
    case_expression |
    function_invocation |
    arithmetic_cast_function |
    (subquery)
string_expression ::=
    state_valued_path_expression |
    string_literal |
    input_parameter |
    functions_returning_strings |
    aggregate_expression |
    case_expression |
    function_invocation |
    string_cast_function |
    string_expression || string_expression |
    (subquery)
datetime_expression ::=
    state_valued_path_expression |
    input_parameter |
    functions_returning_datetime |
    aggregate_expression |
    case_expression |
    function_invocation |
    date_time_timestamp_literal |
    (subquery)
boolean_expression ::=
    state_valued_path_expression |
    boolean_literal |
    input_parameter |
    case_expression |
    function_invocation |
    (subquery)
enum_expression ::=
    state_valued_path_expression |
    enum_literal |
    input_parameter |
    case_expression |
    (subquery)
entity_expression ::= single_valued_object_path_expression | simple_entity_expression
simple_entity_expression ::= identification_variable | input_parameter
entity_type_expression ::=
    type_discriminator |
    entity_type_literal |
    input_parameter
type_discriminator ::=
    TYPE(general_identification_variable |
        single_valued_object_path_expression |
        input_parameter)
arithmetic_cast_function::=
    CAST(string_expression AS {INTEGER | LONG | FLOAT | DOUBLE})
functions_returning_numerics ::=
    LENGTH(string_expression) |
    LOCATE(string_expression, string_expression[, arithmetic_expression]) |
    ABS(arithmetic_expression) |
    CEILING(arithmetic_expression) |
    EXP(arithmetic_expression) |
    FLOOR(arithmetic_expression) |
    LN(arithmetic_expression) |
    SIGN(arithmetic_expression) |
    SQRT(arithmetic_expression) |
    MOD(arithmetic_expression, arithmetic_expression) |
    POWER(arithmetic_expression, arithmetic_expression) |
    ROUND(arithmetic_expression, arithmetic_expression) |
    SIZE(collection_valued_path_expression) |
    INDEX(identification_variable) |
    extract_datetime_field
functions_returning_datetime ::=
    CURRENT_DATE |
    CURRENT_TIME |
    CURRENT_TIMESTAMP |
    LOCAL DATE |
    LOCAL TIME |
    LOCAL DATETIME |
    extract_datetime_part
string_cast_function::=
    CAST(scalar_expression AS STRING)
functions_returning_strings ::=
    CONCAT(string_expression, string_expression{, string_expression}*) |
    SUBSTRING(string_expression, arithmetic_expression[, arithmetic_expression]) |
    TRIM([[trim_specification] [trim_character] FROM] string_expression) |
    LOWER(string_expression) |
    UPPER(string_expression)
trim_specification ::= LEADING | TRAILING | BOTH
function_invocation ::= FUNCTION(function_name{, function_arg}*)
extract_datetime_field :=
    EXTRACT(datetime_field FROM datetime_expression)
datetime_field := identification_variable
extract_datetime_part :=
    EXTRACT(datetime_part FROM datetime_expression)
datetime_part := identification_variable
function_arg ::=
    literal |
    state_valued_path_expression |
    input_parameter |
    scalar_expression
entity_id_or_version_function ::= id_function | version_function
id_function ::=
    ID(general_identification_variable |
       single_valued_object_path_expression)
version_function ::=
    VERSION(general_identification_variable |
            single_valued_object_path_expression)
case_expression ::=
    general_case_expression |
    simple_case_expression |
    coalesce_expression |
    nullif_expression
general_case_expression::= CASE when_clause {when_clause}* ELSE scalar_expression END
when_clause ::= WHEN conditional_expression THEN scalar_expression
simple_case_expression ::=
    CASE case_operand simple_when_clause {simple_when_clause}*
    ELSE scalar_expression
    END
case_operand ::= state_valued_path_expression | type_discriminator
simple_when_clause ::= WHEN scalar_expression THEN scalar_expression
coalesce_expression ::= COALESCE(scalar_expression{, scalar_expression}+)
nullif_expression::= NULLIF(scalar_expression, scalar_expression)

5. Metamodel API

This specification provides a set of interfaces for dynamically accessing a metamodel representing the managed classes of a persistence unit. Instances of metamodel types may be obtained either:

  • via programmatic lookup using an instance of the interface Metamodel (found in Section D.1) obtained from the EntityManagerFactory or EntityManager by calling getMetamodel(), or

  • in a typesafe way, using static metamodel classes.

A static metamodel class is a class with static members providing direct typesafe access to metamodel objects representing the persistent members of a given managed class.

5.1. Static Metamodel Classes

A set of static metamodel classes corresponding to the managed classes of a persistence unit can be generated using an annotation processor or may be created by the application developer.

In the typical case, an annotation processor is used to generate static metamodel classes corresponding to the entities, mapped superclasses, and embeddable classes in the persistence unit. A static metamodel class models the persistent state and relationships of the corresponding managed class. For portability, an annotation processor should generate a canonical metamodel as specified in the next section.

5.1.1. Canonical Metamodel

This specification defines as follows a canonical metamodel and the structure of canonical metamodel classes.

For every managed class in the persistence unit, a corresponding metamodel class is produced as follows:

  • For each managed class X in package p, a metamodel class X_ in package p is created.[81]

  • The name of the metamodel class is derived from the name of the managed class by appending “_” to the name of the managed class.

  • The metamodel class X_ must be annotated with the StaticMetamodel annotation found in Section D.2.[82]

  • If the managed class X extends another class S, where S is the most derived managed class (i.e., entity or mapped superclass) extended by X, then the metamodel class X_ must extend the metamodel class S_ created for S.

  • The metamodel class must contain a field declaration as follows:

    public static volatile jakarta.persistence.metamodel.T<X> class_;

    where T is EntityType, EmbeddableType, or MappedSuperclassType depending on whether X is an entity, embeddable, or mapped superclass.

  • For every persistent attribute y declared by class X, the metamodel class must contain a field declaration as follows:

    public static final String Y = "y";

    where the field name Y is obtained by transforming each lowercase character in the attribute name y to uppercase, inserting an underscore if the character following the transformed character is uppercase, and then replacing each character which is not a legal Java identifier character with an underscore.

  • For every persistent non-collection-valued attribute y declared by class X, where the type of y is Y, the metamodel class must contain a declaration as follows:

    public static volatile SingularAttribute<X, Y> y;
  • For every persistent collection-valued attribute z declared by class X, where the element type of z is Z, the metamodel class must contain a declaration as follows:

    • if the collection type of z is java.util.Collection, then

      public static volatile CollectionAttribute<X, Z> z;
    • if the collection type of z is java.util.Set, then

      public static volatile SetAttribute<X, Z> z;
    • if the collection type of z is java.util.List, then

      public static volatile ListAttribute<X, Z> z;
    • if the collection type of z is java.util.Map, then

      public static volatile MapAttribute<X, K, Z> z;

      where K is the type of the key of the map in class X

  • For every named query, named entity graph, or SQL result set mapping with name "n" declared by annotations of the class X, the metamodel class must contain a declaration as follows:

    public static final String T_N = "n";

    where the prefix T is the string QUERY, GRAPH, or MAPPING, as appropriate, depending on the annotation type, and the suffix N is obtained by transforming each lowercase character in the name n to uppercase, inserting an underscore if the character following the transformed character is uppercase, and then replacing each character which is not a legal Java identifier character with an underscore.

  • For every named query with name "n" and query result class R declared by annotations of the class X, the metamodel class must contain a declaration as follows:

    public static volatile TypedQueryReference<R> _n_;

    where n is the name "n" with every character which is not a legal Java identifier character replaced with an underscore.

  • For every named entity graph with name "n" declared by annotations of the class X, the metamodel class must contain a declaration as follows:

    public static volatile EntityGraph<X> _n;

    where n is the name "n" with every character which is not a legal Java identifier character replaced with an underscore.

Import statements must be included for the needed jakarta.persistence and jakarta.persistence.metamodel types as appropriate and all classes X, Y, Z, R, and K.

Implementations of this specification are not required to resolve naming collisions resulting from the rules above when generating canonical metamodel classes.

Implementations of this specification are not required to support the use of non-canonical metamodel classes. Applications that use non-canonical metamodel classes will not be portable.

5.1.1.1. Example Canonical Metamodel

Assume the Order entity below.

package com.example;

import java.util.Set;
import java.math.BigDecimal;
import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import jakarta.persistence.ManyToOne;
import jakarta.persistence.OneToMany;

@Entity
public class Order {
    @Id
    Integer orderId;

    @ManyToOne
    Customer customer;

    @OneToMany
    Set<Item> lineItems;

    Address shippingAddress;

    BigDecimal totalCost;

    // ...
}

The corresponding canonical metamodel class, Order_, is as follows:

package com.example;

import java.math.BigDecimal;
import jakarta.persistence.metamodel.EntityType;
import jakarta.persistence.metamodel.SingularAttribute;
import jakarta.persistence.metamodel.SetAttribute;
import jakarta.persistence.metamodel.StaticMetamodel;

@StaticMetamodel(Order.class)
public class Order_ {
    public static volatile EntityType<Order> class_;

    public static volatile SingularAttribute<Order, Integer> orderId;
    public static volatile SingularAttribute<Order, Customer> customer;
    public static volatile SetAttribute<Order, Item> lineItems;
    public static volatile SingularAttribute<Order, Address> shippingAddress;
    public static volatile SingularAttribute<Order, BigDecimal> totalCost;

    public static final String LINE_ITEMS = "lineItems";
    public static final String ORDER_ID = "orderId";
    public static final String SHIPPING_ADDRESS = "shippingAddress";
    public static final String TOTAL_COST = "totalCost";
    public static final String CUSTOMER = "customer";
}

5.1.2. Bootstrapping the Static Metamodel

When the entity manager factory for a persistence unit is created, it is the responsibility of the persistence provider to initialize the state of the static metamodel classes representing managed classes belonging to the persistence unit. Any generated metamodel classes must be accessible on the classpath.

Persistence providers must support the use of canonical metamodel classes. Persistence providers may, but are not required to, support the use of non-canonical metamodel classes.

5.2. Runtime Access to Metamodel

The interfaces defined in jakarta.persistence.metamodel provide for dynamic access to a metamodel of the persistent state and relationships of the managed classes of a persistence unit.

An instance of Metamodel may be obtained by calling the getMetamodel() method of EntityManagerFactory or EntityManager.

The complete metamodel API may be found in Appendix D.

6. Criteria API

The Jakarta Persistence Criteria API is used to define queries through the construction of object-based query definition objects, rather than use of the string-based approach of the Jakarta Persistence query language described in Chapter 4.

This chapter provides the full definition of the Criteria API.

6.1. Overview

The Jakarta Persistence Criteria API, like the Jakarta Persistence query language is based on the abstract persistence schema of entities, their embedded objects, and their relationships as its data model. This abstract persistence schema is materialized in the form of metamodel objects over which the Criteria API operates. The semantics of criteria queries are designed to reflect those of Jakarta Persistence query language queries.

The complete criteria query API may be found in Appendix C.

The syntax of the Criteria API is designed to allow the construction of an object-based query “graph”, whose nodes correspond to the semantic query elements.

Java language variables can be used to reference individual nodes in a criteria query object as it is constructed and/or modified. Such variables, when used to refer to the entities and embeddable types that constitute the query domain, play a role analogous to that of the identification variables of the Jakarta Persistence query language.

These concepts are further described in the sections that follow. Sections Section 6.2 through Section 6.6 describe the construction and modification of criteria query objects. Additional requirements on the persistence provider are described in Section 6.7.

The metamodel on which criteria queries are based was already presented in Chapter 5. The static metamodel classes which are used to construct strongly-typed criteria queries are described in Section 5.1.

6.2. Criteria Query API Usage

The jakarta.persistence.criteria API interfaces are designed both to allow criteria queries to be constructed in a strongly-typed manner, using metamodel objects to provide type safety, and to allow for string-based use as an alternative:

Metamodel objects are used to specify navigation through joins and through path expressions[83]. Typesafe navigation is achieved by specification of the source and target types of the navigation.

Strings may be used as an alternative to metamodel objects, whereby joins and navigation are specified by use of strings that correspond to attribute names.

Using either the approach based on metamodel objects or the string-based approach, queries can be constructed both statically and dynamically. Both approaches are equivalent in terms of the range of queries that can be expressed and operational semantics.

Section 6.3 provides a description of the use of the criteria API interfaces. This section is illustrated on the basis of the construction of strongly-typed queries using static metamodel classes. Section 6.4 describes how the jakarta.persistence.metamodel API can be used to construct strongly-typed queries in the absence of such classes. String-based use of the criteria API is described in Section 6.5.

6.3. Constructing Criteria Queries

A criteria query is constructed through the creation and modification of an instance of the CriteriaQuery interface found in Section C.3.

The CriteriaBuilder interface found in Section C.1 is used to construct CriteriaQuery, CriteriaUpdate, and CriteriaDelete objects. The CriteriaBuilder implementation is accessed through the getCriteriaBuilder method of the EntityManager or EntityManagerFactory interface.

For example:

@PersistenceUnit
EntityManagerFactory emf;

CriteriaBuilder cb = emf.getCriteriaBuilder();

6.3.1. CriteriaQuery Creation

A CriteriaQuery object is created by means of one of the createQuery methods or the createTupleQuery method of the CriteriaBuilder interface. A CriteriaQuery object is typed according to its expected result type when the CriteriaQuery object is created. A TypedQuery instance created from the CriteriaQuery object by means of the EntityManager createQuery method will result in instances of this type when the resulting query is executed.

The following methods are provided for the creation of CriteriaQuery objects:

<T> CriteriaQuery<T> createQuery(Class<T> resultClass);

CriteriaQuery<Tuple> createTupleQuery();

CriteriaQuery<Object> createQuery();

Methods for the creation of update and delete queries are described in Section 6.3.15.

The methods <T> CriteriaQuery<T> createQuery(Class<T> resultClass) and createTupleQuery provide for typing of criteria query results and for typesafe query execution using the TypedQuery API.

The effect of the createTupleQuery method is semantically equivalent to invoking the createQuery method with the Tuple.class argument. The Tuple interface supports the extraction of multiple selection items in a strongly typed manner. See Section B.9 and Section B.10.

The CriteriaQuery<Object> createQuery() method supports both the case where the select or multiselect method specifies only a single selection item and where the multiselect method specifies multiple selection items. If only a single item is specified, an instance of type Object will be returned for each result of the query execution. If multiple selection items are specified, an instance of type Object[] will be instantiated and returned for each result of the execution.

See Section 6.3.11 for further discussion of the specification of selection items.

6.3.2. Query Roots

A CriteriaQuery object defines a query over one or more entity, embeddable, or basic abstract schema types. The root objects of the query are entities, from which the other types are reached by navigation. A query root plays a role analogous to that of a range variable in the Jakarta Persistence query language and forms the basis for defining the domain of the query.

A query root is created and added to the query by use of the from method of the AbstractQuery interface (from which both the CriteriaQuery and Subquery interfaces inherit). The argument to the from method is the entity class or EntityType instance for the entity. The result of the from method is a Root object. The Root interface extends the From interface, which represents objects that may occur in the from clause of a query.

A CriteriaQuery object may have more than one root. The addition of a query root has the semantic effect of creating a cartesian product between the entity type referenced by the added root and those of the other roots.

The following query illustrates the definition of a query root. When executed, this query causes all instances of the Customer entity to be returned.

CriteriaBuilder cb = ...
CriteriaQuery<Customer> q = cb.createQuery(Customer.class);
Root<Customer> customer = q.from(Customer.class);
q.select(customer);

6.3.3. Joins

The join methods of the From interface extend the query domain by creating a join with a related class that can be navigated to or that is an element of the given class of the query domain.

The target of the join is specified by the corresponding SingularAttribute or collection-valued attribute ( CollectionAttribute, SetAttribute, ListAttribute, or MapAttribute) of the corresponding metamodel class.[84] [85]

The join methods may be applied to instances of the Root and Join types.

The result of a join method is a Join object (instance of the Join, CollectionJoin, SetJoin, ListJoin, or MapJoin types) that captures the source and target types of the join.

For example, given the Order entity and corresponding Order_ metamodel class shown in Section 5.1.1.1, a join to the lineItems of the order would be expressed as follows:

CriteriaQuery<Order> q = cb.createQuery(Order.class);
Root<Order> order = q.from(Order.class);
Join<Order, Item> item = order.join(Order_.lineItems);
q.select(order);

The argument to the join method, Order.lineItems, is of type jakarta.persistence.metamodel.SetAttribute<Order, Item>.

The join methods have the same semantics as the corresponding Jakarta Persistence query language operations, as described in Section 4.4.7.

Example:

CriteriaBuilder cb = ...
CriteriaQuery<String> q = cb.createQuery(String.class);
Root<Customer> customer = q.from(Customer.class);
Join<Customer, Order> order = customer.join(Customer_.orders);
Join<Order, Item> item = order.join(Order_.lineItems);
q.select(customer.get(Customer_.name))
    .where(cb.equal(item.get(Item_.product).get(Product_.productType), "printer"));

This query is equivalent to the following Jakarta Persistence query language query:

SELECT c.name
FROM Customer c JOIN c.orders o JOIN o.lineItems i
WHERE i.product.productType = 'printer'

Joins can be chained, thus allowing this query to be written more concisely:

CriteriaQuery<String> q = cb.createQuery(String.class);
Root<Customer> customer = q.from(Customer.class);
Join<Order, Item> item = customer.join(Customer_.orders).join(Order_.lineItems);
q.select(customer.get(Customer_.name))
    .where(cb.equal(item.get(Item_.product).get(Product_.productType), "printer"));

By default, the join method defines an inner join. Outer joins are defined by explicitly specifying a JoinType argument.

The following query uses a left outer join:

CriteriaQuery<Customer> q = cb.createQuery(Customer.class);
Root<Customer> customer = q.from(Customer.class);
Join<Customer,Order> order = customer.join(Customer_.orders, JoinType.LEFT);
q.where(cb.equal(customer.get(Customer_.status), 1))
    .select(customer);

This query is equivalent to the following Jakarta Persistence query language query:

SELECT c FROM Customer c LEFT JOIN c.orders o WHERE c.status = 1

On-conditions can be specified for joins. The following query uses an on-condition with a left outer join:

CriteriaQuery<Tuple> q = cb.createTupleQuery();
Root<Supplier> s = q.from(Supplier.class);
Join<Supplier, Product> p = s.join(Supplier_.products, JoinType.LEFT);
p.on(cb.equal(p.get(Product_.status), "inStock"));
q.groupBy(s.get(Supplier_.name));
q.multiselect(s.get(Supplier_.name), cb.count(p));

This query is equivalent to the following Jakarta Persistence query language query:

SELECT s.name, COUNT(p)
FROM Suppliers s LEFT JOIN s.products p ON p.status = 'inStock'
GROUP BY s.name

6.3.4. Fetch Joins

Fetch joins are specified by means of the fetch method. The fetch method specifies that the referenced association or attribute is to be fetched as a side effect of the execution of the query. The fetch method can be applied to a Root or Join instance.

An association or attribute referenced by the fetch method must be referenced from an entity or embeddable that is returned as the result of the query. A fetch join has the same join semantics as the corresponding inner or outer join, except that the related objects are not top-level objects in the query result and cannot be referenced elsewhere by the query. See Section 4.4.5.3.

The fetch method must not be used in a subquery.

Multiple levels of fetch joins are not required to be supported by an implementation of this specification. Applications that use multi-level fetch joins will not be portable.

Example:

CriteriaQuery<Department> q = cb.createQuery(Department.class);
Root<Department> d = q.from(Department.class);
d.fetch(Department.employees, JoinType.LEFT);
q.where(cb.equal(d.get(Department_.deptno), 1)).select(d);

This query is equivalent to the following Jakarta Persistence query language query:

SELECT d
FROM Department d LEFT JOIN FETCH d.employees
WHERE d.deptno = 1

6.3.5. Path Navigation

A Path instance can be a Root instance, a Join instance, a Path instance that has been derived from another Path instance by means of the get navigation method, or a Path instance derived from a map-valued association or element collection by use of the key or value method.

When a criteria query is executed, path navigation—like path navigation using the Jakarta Persistence query language—is obtained using “inner join” semantics. That is, if the value of a non-terminal Path instance is null, the path is considered to have no value, and does not participate in the determination of the query result. See Section 4.4.4.

The get method is used for path navigation. The argument to the get method is specified by the corresponding SingularAttribute or collection-valued attribute (CollectionAttribute, SetAttribute, ListAttribute, or MapAttribute) of the corresponding metamodel class[86].

Example 1:

In the following example, ContactInfo is an embeddable class consisting of an address and set of phones. Phone is an entity.

CriteriaQuery<Vendor> q = cb.createQuery(Vendor.class);
Root<Employee> emp = q.from(Employee.class);
Join<ContactInfo, Phone> phone =
    emp.join(Employee_.contactInfo).join(ContactInfo_.phones);
q.where(cb.equal(emp.get(Employee_.contactInfo)
        .get(ContactInfo_.address)
        .get(Address_.zipcode), "95054"))
    .select(phone.get(Phone_.vendor));

The following Jakarta Persistence query language query is equivalent:

SELECT p.vendor
FROM Employee e JOIN e.contactInfo.phones p
WHERE e.contactInfo.address.zipcode = '95054'

Example 2:

In this example, the photos attribute corresponds to a map from photo label to filename. The map key is a string, the value an object. The result of this query will be returned as a Tuple object whose elements are of types String and Object. The multiselect method, described further in Section 6.3.11, is used to specify that the query returns multiple selection items.

CriteriaQuery<Tuple> q = cb.createTupleQuery();
Root<Item> item = q.from(Item.class);
MapJoin<Item, String, Object> photo = item.join(Item_.photos);
q.multiselect(item.get(Item_.name), photo)
    .where(cb.like(photo.key(), "%egret%"));

This query is equivalent to the following Jakarta Persistence query language query:

SELECT i.name, p
FROM Item i JOIN i.photos p
WHERE KEY(p) LIKE '%egret%'

6.3.6. Restricting the Query Result

The result of a query can be restricted by specifying one or more predicate conditions. Restriction predicates are applied to the CriteriaQuery object by means of the where method. Invocation of the where method results in the modification of the CriteriaQuery object with the specified restriction(s).

The argument to the where method can be either an Expression<Boolean> instance or zero or more Predicate instances. A predicate can be either simple or compound.

A simple predicate is created by invoking one of the conditional methods of the CriteriaBuilder interface, or by the isNull, isNotNull, and in methods of the Expression interface. The semantics of the conditional methods—e.g., equal, notEqual, gt, ge, lt, le, between, and like — mirror those of the corresponding Jakarta Persistence query language operators as described in Chapter 4.

Compound predicates are constructed by means of the and, or, and not methods of the CriteriaBuilder interface.

The restrictions upon the types to which conditional operations are permitted to be applied are the same as the respective operators of the Jakarta Persistence query language as described in subsections Section 4.6.3 through Section 4.7. The same null value semantics as described in Section 4.6.13 and the subsections of Section 4.6 apply. The equality and comparison semantics described in Section 4.6.14 likewise apply.

Example 1:

CriteriaQuery<TransactionHistory> q = cb.createQuery(TransactionHistory.class);
Root<CreditCard> cc = q.from(CreditCard.class);
ListJoin<CreditCard,TransactionHistory> t = cc.join(CreditCard_.transactionHistory);
q.select(t)
    .where(cb.equal(cc.get(CreditCard_.customer)
             .get(Customer_.accountNum), 321987),
           cb.between (t.index(), 0, 9));

This query is equivalent to the following Jakarta Persistence query language query:

SELECT t
FROM CreditCard c JOIN c.transactionHistory t
WHERE c.customer.accountNum = 321987 AND INDEX(t) BETWEEN 0 AND 9

Example 2:

CriteriaQuery<Order> q = cb.createQuery(Order.class);
Root<Order> order = q.from(Order.class);
q.where(cb.isEmpty(order.get(Order_.lineItems)))
    .select(order);

This query is equivalent to the following Jakarta Persistence query language query:

SELECT o
FROM Order o
WHERE o.lineItems IS EMPTY

6.3.7. Downcasting

Downcasting by means of the treat method is supported in joins and in the construction of where conditions.

Example 1:

CriteriaQuery<String> q = cb.createQuery(String.class);
Root<Order> order = q.from(Order.class);
Join<Order,Book> book = cb.treat(order.join(Order_.product), Book.class);
q.select(book.get(Book_.isbn));

This query is equivalent to the following Jakarta Persistence query language query.

SELECT b.ISBN
FROM Order o JOIN TREAT(o.product AS Book) b

Example 2:

CriteriaQuery<Customer> q = cb.createQuery(Customer.class);
Root<Customer> customer = q.from(Customer.class);
Join<Customer, Order> order = customer.join(Customer_.orders);
q.where(
    cb.equal(cb.treat(order.get(Order_.product), Book.class).get(Book_.name), "Iliad"));
q.select(customer);

This query is equivalent to the following Jakarta Persistence query language query:

SELECT c
FROM Customer c JOIN c.orders o
WHERE TREAT(o.product AS Book).name = 'Iliad'

Example 3:

CriteriaQuery<Employee> q = cb.createQuery(Employee.class);
Root<Employee> e = q.from(Employee.class);
q.where(
    cb.or(cb.gt(cb.treat(e, Exempt.class).get(Exempt_.vacationDays), 10),
    cb.gt(cb.treat(e, Contractor.class).get(Contractor_.hours), 100)));

This query is equivalent to the following Jakarta Persistence query language query:

SELECT e
FROM Employee e
WHERE TREAT(e AS Exempt).vacationDays > 10
    OR TREAT(e AS Contractor).hours > 100

6.3.8. Expressions

An Expression or one of its subtypes can be used in the construction of the query’s select list or in the construction of where or having method conditions.

Paths and boolean predicates are expressions.

Other expressions are created by means of the methods of the CriteriaBuilder interface. The CriteriaBuilder interface provides methods corresponding to the built-in arthmetic, string, datetime, and case operators and functions of the Jakarta Persistence query language.

Example 1:

CriteriaQuery<Tuple> q = cb.createTupleQuery();
Root<Customer> cust = q.from(Customer.class);
Join<Customer, Order> order = cust.join(Customer_.orders);
Join<Customer, Address> addr = cust.join(Customer_.address);
q.where(cb.equal(addr.get(Address_.state), "CA"),
        cb.equal(addr.get(Address_.county), "Santa Clara"));

q.multiselect(order.get(Order_.quantity),
        cb.prod(order.get(Order_.totalCost), 1.08),
        addr.get(Address_.zipcode));

The following Jakarta Persistence query language query is equivalent:

SELECT o.quantity, o.totalCost*1.08, a.zipcode
FROM Customer c JOIN c.orders o JOIN c.address a
WHERE a.state = 'CA' AND a.county = 'Santa Clara'

Example 2:

CriteriaQuery<Employee> q = cb.createQuery(Employee.class);
Root<Employee> emp = q.from(Employee.class);
q.select(emp)
    .where(cb.notEqual(emp.type(), Exempt.class));

The type method can only be applied to a path expression. Its result denotes the type navigated to by the path.

The following Jakarta Persistence query language query is equivalent:

SELECT e
FROM Employee e
WHERE TYPE(e) <> Exempt

Example 3:

CriteriaQuery<String> q = cb.createQuery(String.class);
Root<Course> c = q.from(Course.class);
ListJoin<Course, Student> w = c.join(Course_.studentWaitlist);
q.where(cb.equal(c.get(Course_.name), "Calculus"),
        cb.equal(w.index(), 0))
 .select(w.get(Student_.name));

The index method can be applied to a ListJoin object that corresponds to a list for which an order column has been specified. Its result denotes the position of the item in the list.

The following Jakarta Persistence query language query is equivalent:

SELECT w.name
FROM Course c JOIN c.studentWaitlist w
WHERE c.name = 'Calculus' AND INDEX(w) = 0

Example 4:

CriteriaQuery<BigDecimal> q = cb.createQuery(BigDecimal.class);
Root<Order> order = q.from(Order.class);
Join<Order, Item> item = order.join(Order_.lineItems);
Join<Order, Customer> cust = order.join(Order_.customer);

q.where(
    cb.equal(cust.get(Customer_.lastName), "Smith"),
    cb.equal(cust.get(Customer_.firstName), "John"));
q.select(cb.sum(item.get(Item_.price)));

The aggregation methods avg, max, min , sum, count can only be used in the construction of the select list or in having method conditions.

The following Jakarta Persistence query language query is equivalent:

SELECT SUM(i.price)
FROM Order o JOIN o.lineItems i JOIN o.customer c
WHERE c.lastName = 'Smith' AND c.firstName = 'John'

Example 5:

CriteriaQuery<Integer> q = cb.createQuery(Integer.class);
Root<Department> d = q.from(Department.class);
q
    .where(cb.equal(d.get(Department_.name), "Sales"))
    .select(cb.size(d.get(Department_.employees)));

The size method can be applied to a path expression that corresponds to an association or element collection. Its result denotes the number of elements in the association or element collection.

The following Jakarta Persistence query language query is equivalent:

SELECT SIZE(d.employees)
FROM Department d
WHERE d.name = 'Sales'

Example 6:

Both simple and general case expressions are supported. The query below illustrates use of a general case expression.

CriteriaQuery<Tuple> q = cb.createTupleQuery();
Root<Employee> e = q.from(Employee.class);
q.where(
    cb.equal(e.get(Employee_.department).get(Department_.name), "Engineering"));
q.multiselect(
    e.get(Employee_.name),
    cb.selectCase()
        .when(
            cb.equal(e.get(Employee_.rating), 1),
            cb.prod(e.get(Employee_.salary), 1.1))
        .when(
            cb.equal(e.get(Employee_.rating), 2),
            cb.prod(e.get(Employee_.salary), 1.2))
        .otherwise(cb.prod(e.get(Employee_.salary), 1.01)));

The following Jakarta Persistence query language query is equivalent:

SELECT e.name,
    CASE
        WHEN e.rating = 1 THEN e.salary * 1.1
        WHEN e.rating = 2 THEN e.salary * 1.2
        ELSE e.salary * 1.01
    END
FROM EMPLOYEE e
WHERE e.department.name = 'Engineering'
6.3.8.1. Result Types of Expressions

The getJavaType method, as defined in the TupleElement interface, returns the runtime type of the object on which it is invoked.

In the case of the In, Case, SimpleCase, and Coalesce builder interfaces, the runtime results of the getJavaType method may differ from the Expression type and may vary as the expression is incrementally constructed. For non-numerical operands, the implementation must return the most specific common superclass of the types of the operands used to form the result.

In the case of the two-argument sum, prod, diff, quot, coalesce, and nullif methods, and the In, Case, SimpleCase, and Coalesce builder methods, the runtime result types will differ from the Expression type when the latter is Number. The following rules must be observed by the implementation when materializing the results of numeric expressions involving these methods. These rules correspond to those specified for the Jakarta Persistence query language as defined in Section 4.7.13.

  • If there is an operand of type Double, the result of the operation is of type Double;

  • otherwise, if there is an operand of type Float, the result of the operation is of type Float;

  • otherwise, if there is an operand of type BigDecimal, the result of the operation is of type BigDecimal;

  • otherwise, if there is an operand of type BigInteger, the result of the operation is of type BigInteger, unless the method is quot, in which case the numeric result type is not further defined;

  • otherwise, if there is an operand of type Long, the result of the operation is of type Long, unless the method is quot, in which case the numeric result type is not further defined;

  • otherwise, if there is an operand of integral type, the result of the operation is of type Integer, unless the method is quot, in which case the numeric result type is not further defined.

Users should note that the semantics of the SQL division operation are not standard across databases. In particular, when both operands are of integral types, the result of the division operation will be an integral type in some databases, and an non-integral type in others. Portable applications should not assume a particular result type.

6.3.9. Literals

An Expression literal instance is obtained by passing a value to the literal method of the CriteriaBuilder interface. An Expression instance representing a null is created by the nullLiteral method of the CriteriaBuilder interface.

Example:

CriteriaQuery<String> q = cb.createQuery(String.class);
Root<Employee> emp = q.from(Employee.class);
Join<Employee, FrequentFlierPlan> fp = emp.join(Employee_.frequentFlierPlan);

q.select(
    cb.<String>selectCase()
        .when(
            cb.gt(fp.get(FrequentFlierPlan_.annualMiles), 50000),
            cb.literal("Platinum"))
        .when(
            cb.gt(fp.get(FrequentFlierPlan_.annualMiles), 25000),
            cb.literal("Silver"))
        .otherwise(cb.nullLiteral(String.class)));

The following Jakarta Persistence query language query is equivalent:

SELECT
    CASE
        WHEN fp.annualMiles > 50000 THEN 'Platinum'
        WHEN fp.annualMiles > 25000 THEN 'Gold'
        ELSE NULL
    END

6.3.10. Parameter Expressions

A ParameterExpression instance is an expression that corresponds to a parameter whose value will be supplied before the query is executed. Parameter expressions can only be used in the construction of conditional predicates.

Example:

CriteriaQuery<Customer> q = cb.createQuery(Customer.class);
Root<Customer> c = q.from(Customer.class);
ParameterExpression<Integer> param = cb.parameter(Integer.class);

q.select(c)
    .where(cb.equal(c.get(Customer_.status), param));

If a name is supplied when the ParameterExpression instance is created, the parameter may also be treated as a named parameter when the query is executed:

CriteriaQuery<Customer> q =
cb.createQuery(Customer.class);

Root<Customer> c = q.from(Customer.class);
ParameterExpression<Integer> param = cb.parameter(Integer.class, "stat");
q.select(c).where(cb.equal(c.get(Customer_.status), param));

This is equivalent to the following query in the Jakarta Persistence query language:

SELECT c FROM Customer c WHERE c.status = :stat

6.3.11. Specifying the Select List

The select list of a query is specified by use of the select or multiselect methods of the CriteriaQuery interface. The arguments to the select and multiselect methods are Selection instances.

Portable applications should use the select or multiselect method to specify the query’s selection list. Applications that do not use one of these methods will not be portable.

The select method takes a single Selection argument, which can be either an Expression instance or a CompoundSelection instance. The type of the Selection item must be assignable to the defined CriteriaQuery result type, as described in Section 6.3.1.

The construct, tuple and array methods of the CriteriaBuilder interface are used to aggregate multiple selection items into a CompoundSelection instance.

The multiselect method also supports the specification and aggregation of multiple selection items. When the multiselect method is used, the aggregation of the selection items is determined by the result type of the CriteriaQuery object as described in Section 6.3.1.

A Selection instance passed to the construct, tuple, array, or multiselect methods can be one of the following:

  • An Expression instance.

  • A Selection instance obtained as the result of the invocation of the CriteriaBuilder construct method.

The distinct method of the CriteriaQuery interface is used to specify that duplicate values must be eliminated from the query result. If the distinct method is not used or distinct(false) is invoked on the criteria query object, duplicate values are not eliminated. When distinct(true) is used, and the select items include embeddable objects or map entry results, the elimination of duplicates is undefined.

The semantics of the construct method used in the selection list is as described in Section 4.9.2. The semantics of embeddables returned by the selection list areas described in Section 4.9.4.

Example 1:

In the following example, videoInventory is a Map from the entity Movie to the number of copies in stock.

CriteriaQuery<Tuple> q = cb.createTupleQuery();
Root<VideoStore> v = q.from(VideoStore.class);
MapJoin<VideoStore, Movie, Integer> inv = v.join(VideoStore_.videoInventory);

q.multiselect(
    v.get(VideoStore_.location).get(Address_.street),
    inv.key().get(Movie_.title),
    inv);
q.where(cb.equal(v.get(VideoStore_.location).get(Address_.zipcode), "94301"),
        cb.gt(inv, 0));

This query is equivalent to the following, in which the tuple method is used:

CriteriaQuery<Tuple> q = cb.createTupleQuery();
Root<VideoStore> v = q.from(VideoStore.class);
MapJoin<VideoStore, Movie, Integer> inv = v.join(VideoStore_.videoInventory);

q.select(cb.tuple(
        v.get(VideoStore_.location).get(Address_.street),
        inv.key().get(Movie_.title),
        inv));
q.where(cb.equal(v.get(VideoStore_.location).get(Address_.zipcode), "94301"),
        cb.gt(inv, 0));

Both are equivalent to the following Jakarta Persistence query language query:

SELECT v.location.street, KEY(i).title, VALUE(i)
FROM VideoStore v JOIN v.videoInventory i
WHERE v.location.zipcode = '94301' AND VALUE(i) > 0

Example 2:

The following two queries are equivalent to the Jakarta Persistence query language query above. Because the result type is not specified by the createQuery method, an Object[] is returned as a result of the query execution:

CriteriaQuery<Object> q = cb.createQuery();
Root<VideoStore> v = q.from(VideoStore.class);
MapJoin<VideoStore, Movie, Integer> inv = v.join(VideoStore_.videoInventory);

q.multiselect(
    v.get(VideoStore_.location).get(Address_.street),
    inv.key().get(Movie_.title),
    inv);

q.where(cb.equal(v.get(VideoStore_.location).get(Address_.zipcode), "94301"),
        cb.gt(inv, 0));

Equivalently:

CriteriaQuery<Object> q = cb.createQuery();
Root<VideoStore> v = q.from(VideoStore.class);
MapJoin<VideoStore, Movie, Integer> inv = v.join(VideoStore_.videoInventory);

q.select(cb.array(
        v.get(VideoStore_.location).get(Address_.street),
        inv.key().get(Movie_.title),
        inv));
q.where(cb.equal(v.get(VideoStore_.location).get(Address_.zipcode), "94301"),
        cb.gt(inv, 0));

Example 3:

The following example illustrates the specification of a constructor.

CriteriaQuery<CustomerDetails> q = cb.createQuery(CustomerDetails.class);
Root<Customer> c = q.from(Customer.class);
Join<Customer, Order> o = c.join(Customer_.orders);

q.where(cb.gt(o.get(Order_.quantity), 100));
q.select(cb.construct(
        CustomerDetails.class,
        c.get(Customer_.id),
        c.get(Customer_.status),
        o.get(Order_.quantity)));

The following Jakarta Persistence query language query is equivalent:

SELECT NEW com.acme.example.CustomerDetails(c.id, c.status, o.quantity)
FROM Customer c JOIN c.orders o
WHERE o.quantity > 100
6.3.11.1. Assigning Aliases to Selection Items

The alias method of the Selection interface can be used to assign an alias to a selection item. The alias may then later be used to extract the corresponding item from the query result when the query is executed. The alias method assigns the given alias to the Selection item. Once assigned, the alias cannot be changed.

Example:

CriteriaQuery<Tuple> q = cb.createTupleQuery();
Root<Customer> c = q.from(Customer.class);
Join<Customer, Order> o = c.join(Customer_.orders);
Join<Customer, Address> a = c.join(Customer_.address);

q.where(cb.equal(c.get(Customer_.id), 97510));
q.multiselect(
        o.get(Order_.quantity).alias("quantity"),
        cb.prod(o.get(Order_.totalCost), 1.08).alias("taxedCost"),
        a.get(Address_.zipcode).alias("zipcode"));

TypedQuery<Tuple> typedQuery = em.createQuery(q);
Tuple result = typedQuery.getSingleResult();
Double cost = (Double)result.get("taxedCost");

6.3.12. Subqueries

Both correlated and non-correlated subqueries can be used in restriction predicates. A subquery is constructed through the creation and modification of a Subquery object.

A Subquery instance can be passed as an argument to the all, any, or some methods of the CriteriaBuilder interface for use in conditional expressions.

A Subquery instance can be passed to the CriteriaBuilder exists method to create a conditional predicate.

Example 1: Non-correlated subquery

The query below contains a non-correlated subquery. A non-correlated subquery does not reference objects of the query of which it is a subquery. In particular, Root, Join, and Path instances are not shared between the subquery and the criteria query instance of which it is a subquery.

// create criteria query instance, with root Customer
CriteriaQuery<Customer> q = cb.createQuery(Customer.class);
Root<Customer> goodCustomer = q.from(Customer.class);

// create subquery instance, with root Customer
// the Subquery object is typed according to its return type
Subquery<Double> sq = q.subquery(Double.class);
Root<Customer> customer = sq.from(Customer.class);

// the result of the first query depends on the subquery
q.where(cb.lt(
    goodCustomer.get(Customer_.balanceOwed),
    sq.select(cb.avg(customer.get(Customer_.balanceOwed)))));
q.select(goodCustomer);

This query corresponds to the following Jakarta Persistence query language query.

SELECT goodCustomer
FROM Customer goodCustomer
WHERE goodCustomer.balanceOwed < (SELECT AVG(c.balanceOwed) FROM Customer c)

Example 2: Correlated subquery

// create CriteriaQuery instance, with root Employee
CriteriaQuery<Employee> q = cb.createQuery(Employee.class);
Root<Employee> emp = q.from(Employee.class);

// create Subquery instance, with root Employee
Subquery<Employee> sq = q.subquery(Employee.class);
Root<Employee> spouseEmp = sq.from(Employee.class);

// the subquery references the root of the containing query
sq.where(cb.equal(spouseEmp, emp.get(Employee_.spouse)))
    .select(spouseEmp);

// an exists condition is applied to the subquery result:
q.where(cb.exists(sq));
q.select(emp).distinct(true);

The above query corresponds to the following Jakarta Persistence query language query.

SELECT DISTINCT emp
FROM Employee emp
WHERE EXISTS (
    SELECT spouseEmp
    FROM Employee spouseEmp
    WHERE spouseEmp = emp.spouse)

Example 3: Subquery qualified by all()

// create CriteriaQuery instance, with root Employee
CriteriaQuery<Employee> q = cb.createQuery(Employee.class);
Root<Employee> emp = q.from(Employee.class);

// create Subquery instance, with root Manager
Subquery<BigDecimal> sq = q.subquery(BigDecimal.class);
Root<Manager> manager = sq.from(Manager.class);

sq.select(manager.get(Manager_.salary));
sq.where(cb.equal(
    manager.get(Manager_.department),
    emp.get(Employee_.department)));

// an all expression is applied to the subquery result
q.select(emp)
    .where(cb.gt(emp.get(Employee_.salary), cb.all(sq)));

This query corresponds to the following Jakarta Persistence query language query:

SELECT emp
FROM Employee emp
WHERE emp.salary > ALL (
    SELECT m.salary
    FROM Manager m
    WHERE m.department = emp.department)

Example 4: A Special case

In order to express some correlated subqueries involving unidirectional relationships, it may be useful to correlate the domain of the subquery with the domain of the containing query. This is performed by using the correlate method of the Subquery interface.

For example:

CriteriaQuery<Customer> q = cb.createQuery(Customer.class);
Root<Customer> customer = q.from(Customer.class);
Subquery<Long> sq = q.subquery(Long.class);
Root<Customer> customerSub = sq.correlate(customer);
Join<Customer,Order> order = customerSub.join(Customer_.orders);

q.where(cb.gt(sq.select(cb.count(order)), 10))
    .select(customer);

This query corresponds to the following Jakarta Persistence query language query:

SELECT c
FROM Customer c
WHERE (SELECT COUNT(o) FROM c.orders o) > 10

Note that joins involving the derived subquery root do not affect the join conditions of the containing query. The following two query definitions thus differ in semantics:

CriteriaQuery<Order> q = cb.createQuery(Order.class);
Root<Order> order = q.from(Order.class);
Subquery<Integer> sq = q.subquery(Integer.class);
Root<Order> orderSub = sq.correlate(order);
Join<Order,Customer> customer = orderSub.join(Order_.customer);
Join<Customer,Account> account = customer.join(Customer_.accounts);

sq.select(account.get(Account_.balance));
q.where(cb.lt(cb.literal(10000), cb.all(sq)));

and

CriteriaQuery<Order> q = cb.createQuery(Order.class);
Root<Order> order = q.from(Order.class);
Join<Order,Customer> customer = order.join(Order_.customer);
Subquery<Integer> sq = q.subquery(Integer.class);
Join<Order,Customer> customerSub = sq.correlate(customer);
Join<Customer,Account> account = customerSub.join(Customer_.accounts);

sq.select(account.get(Account_.balance));
q.where(cb.lt(cb.literal(10000), cb.all(sq)));

The first of these queries will return orders that are not associated with customers, whereas the second will not. The corresponding Jakarta Persistence query language queries are the following:

SELECT o
FROM Order o
WHERE 10000 < ALL (
    SELECT a.balance
    FROM o.customer c JOIN c.accounts a)

and

SELECT o
FROM Order o JOIN o.customer c
WHERE 10000 < ALL (
    SELECT a.balance
    FROM c.accounts a)

6.3.13. GroupBy and Having

The groupBy method of the CriteriaQuery interface is used to define a partitioning of the query results into groups. The having method of the CriteriaQuery interface can be used to filter over the groups.

The arguments to the groupBy method are Expression instances.

When the groupBy method is used, each selection item that is not the result of applying an aggregate method must correspond to a path expression that is used for defining the grouping. Requirements on the types that correspond to the elements of the grouping and having constructs and their relationship to the select items are as specified in Section 4.8.

Example:

CriteriaQuery<Tuple> q = cb.createTupleQuery();
Root<Customer> customer = q.from(Customer.class);

q.groupBy(customer.get(Customer_.status));
q.having(cb.in(customer.get(Customer_.status)).value(1).value(2));
q.select(cb.tuple(
        customer.get(Customer_.status),
        cb.avg(customer.get(Customer_.filledOrderCount)),
        cb.count(customer)));

This query is equivalent to the following Jakarta Persistence query language query:

SELECT c.status, AVG(c.filledOrderCount), COUNT(c)
FROM Customer c
GROUP BY c.status
HAVING c.status IN (1, 2)

6.3.14. Ordering the Query Results

The ordering of the results of a query is defined by use of the orderBy method of the CriteriaQuery instance. The arguments to the orderBy method are Order instances.

An Order instance is created by means of the asc and desc methods of the CriteriaBuilder interface. An argument to either of these methods must be one of the following:

  • Any Expression instance that corresponds to an orderable state field of an entity or embeddable class abstract schema type that is specified as an argument to the select or multiselect method or that is an argument to a tuple or array constructor that is passed as an argument to the select method.

  • Any Expression instance that corresponds to the same state field of the same entity or embeddable abstract schema type as an Expression instance that is specified as an argument to the select or multiselect method or that is an argument to a tuple or array constructor that is passed as an argument to the select method.

  • An Expression instance that is specified as an argument to the select or multiselect method or that is an argument to a tuple or array constructor that is passed as an argument to the select method or that is semantically equivalent to such an Expression instance.

If more than one Order instance is specified, the order in which they appear in the argument list of the orderBy method determines the precedence, whereby the first item has highest precedence.

SQL rules for the ordering of null values apply, as described in Section 4.10.

Example 1:

CriteriaQuery<Order> q = cb.createQuery(Order.class);
Root<Customer> c = q.from(Customer.class);
Join<Customer,Order> o = c.join(Customer_.orders);
Join<Customer,Address> a = c.join(Customer_.address);

q.where(cb.equal(a.get(Address_.state), "CA"));
q.select(o);
q.orderBy(cb.desc(o.get(Order_.quantity)),
    cb.asc(o.get(Order_.totalCost)));

This query corresponds to the following Jakarta Persistence query language query:

SELECT o
FROM Customer c JOIN c.orders o JOIN c.address a
WHERE a.state = 'CA'
ORDER BY o.quantity DESC, o.totalcost

Example 2:

CriteriaQuery<Tuple> q = cb.createTupleQuery();
Root<Customer> c = q.from(Customer.class);
Join<Customer, Order> o = c.join(Customer_.orders);
Join<Customer, Address> a = c.join(Customer_.address);

q.where(cb.equal(a.get(Address_.state), "CA"));
q.orderBy(cb.asc(o.get(Order_.quantity)),
    cb.asc(a.get(Address_.zipcode)));
q.multiselect(o.get(Order_.quantity),
    a.get(Address_.zipcode));

This query corresponds to the following Jakarta Persistence query language query:

SELECT o.quantity, a.zipcode
FROM Customer c JOIN c.orders o JOIN c.address a
WHERE a.state = 'CA'
ORDER BY o.quantity, a.zipcode

It can be equivalently expressed as follows:

CriteriaQuery<Tuple> q = cb.createTupleQuery();
Root<Customer> c = q.from(Customer.class);
Join<Customer, Order> o = c.join(Customer_.orders);
Join<Customer, Address> a = c.join(Customer_.address);

q.where(cb.equal(a.get(Address_.state), "CA"));
q.orderBy(cb.asc(o.get(Order_.quantity)),
    cb.asc(a.get(Address_.zipcode)));
q.select(cb.tuple(o.get(Order_.quantity),
    a.get(Address_.zipcode)));

Example 3:

CriteriaQuery<Object[]> q = cb.createQuery(Object[].class);
Root<Customer> c = q.from(Customer.class);
Join<Customer, Order> o = c.join(Customer_.orders);
Join<Customer, Address> a = c.join(Customer_.address);

q.where(cb.equal(a.get(Address_.state), "CA"),
    cb.equal(a.get(Address_.county), "Santa Clara"));
q.select(cb.array(o.get(Order_.quantity),
    cb.prod(o.get(Order_.totalCost), 1.08),
    a.get(Address_.zipcode)));
q.orderBy(cb.asc(o.get(Order_.quantity)),
    cb.asc(cb.prod(o.get(Order_.totalCost), 1.08)),
    cb.asc(a.get(Address_.zipcode)));

This query corresponds to the following Jakarta Persistence query language query:

SELECT o.quantity, o.totalCost * 1.08 AS taxedCost, a.zipcode
FROM Customer c JOIN c.orders o JOIN c.address a
WHERE a.state = 'CA' AND a.county = 'Santa Clara'
ORDER BY o.quantity, taxedCost, a.zipcode

6.3.15. Bulk Update and Delete Operations

A bulk update query is constructed through the creation and modification of a jakarta.persistence.criteria.CriteriaUpdate object.

A CriteriaUpdate object is created by means of one of the createCriteriaUpdate methods of the CriteriaBuilder interface. A CriteriaUpdate object is typed according to the entity type that is the target of the update. A CriteriaUpdate object has a single root, the entity that is being updated.

A bulk delete query is constructed through the creation and modification of a jakarta.persistence.criteria.CriteriaDelete object.

A CriteriaDelete object is created by means of one of the createCriteriaDelete methods of the CriteriaBuilder interface. A CriteriaDelete object is typed according to the entity type that is the target of the delete. A CriteriaDelete object has a single root, the entity that is being deleted.

Example 1:

CriteriaUpdate<Customer> q = cb.createCriteriaUpdate(Customer.class);
Root<Customer> c = q.from(Customer.class);

q.set(c.get(Customer_.status), "outstanding")
    .where(cb.lt(c.get(Customer_.balance), 10000));

The following Jakarta Persistence query language update statement is equivalent.

UPDATE Customer c
SET c.status = 'outstanding'
WHERE c.balance < 10000

Example 2:

CriteriaUpdate<Employee> q = cb.createCriteriaUpdate(Employee.class);
Root<Employee> e = q.from(Employee.class);

q.set(e.get(Employee_.address).get(Address_.building), 22)
    .where(
        cb.equal(e.get(Employee_.address).get(Address_.building), 14),
        cb.equal(e.get(Employee_.address).get(Address_.city), "Santa Clara"),
        cb.equal(e.get(Employee_.project).get(Project_.name), "Jakarta EE"));

Address is an embeddable class. Note that updating across implicit joins is not supported.

The following Jakarta Persistence query language update statement is equivalent.

UPDATE Employee e
SET e.address.building = 22
WHERE e.address.building = 14
    AND e.address.city = 'Santa Clara'
    AND e.project.name = 'Jakarta EE'

Example 3:

The following update query causes multiple attributes to be updated.

CriteriaUpdate<Employee> q = cb.createCriteriaUpdate(Employee.class);
Root<Employee> e = q.from(Employee.class);

q.set(e.get(Employee_.salary), cb.prod(e.get(Employee_.salary), 1.1f))
    .set(e.get(Employee_.commission), cb.prod(e.get(Employee_.commission), 1.1f))
    .set(e.get(Employee_.bonus), cb.sum(e.get(Employee_.bonus), 5000))
    .where(cb.equal(e.get(Employee_.dept).get(Department_.name), "Sales"));

The following Jakarta Persistence query language update statement is equivalent.

UPDATE Employee e
SET e.salary = e.salary * 1.1,
    e.commission = e.commission * 1.1,
    e.bonus = e.bonus + 5000
WHERE e.dept.name = 'Sales'

Example 4:

CriteriaDelete<Customer> q = cb.createCriteriaDelete(Customer.class);
Root<Customer> c = q.from(Customer.class);

q.where(
    cb.equal(c.get(Customer_.status), "inactive"),
    cb.isEmpty(c.get(Customer_.orders)));

The following Jakarta Persistence query language delete statement is equivalent.

DELETE
FROM Customer c
WHERE c.status = 'inactive'
    AND c.orders IS EMPTY

Like bulk update and delete operations made through the Jakarta Persistence query language, criteria API bulk update and delete operations map directly to database operations, bypassing any optimistic locking checks. Portable applications using bulk update operations must manually update the value of the version column, if desired, and/or manually validate the value of the version column.

The persistence context is not synchronized with the result of the bulk update or delete. See Section 4.11.

6.4. Constructing Strongly-typed Queries using the jakarta.persistence.metamodel Interfaces

Strongly-typed queries can also be constructed, either statically or dynamically, in the absence of generated metamodel classes. The jakarta.persistence.metamodel interfaces are used to access the metamodel objects that correspond to the managed classes.

The following examples illustrate this approach. These are equivalent to the example queries shown in Section 6.3.5.

The Metamodel interface is obtained from the EntityManager or EntityManagerFactory for the persistence unit, and then used to obtain the corresponding metamodel objects for the managed types referenced by the queries.

Example 1:

EntityManager em = ...;

Metamodel mm = em.getMetamodel();
EntityType<Employee> emp_ =mm.entity(Employee.class);
EmbeddableType<ContactInfo> cinfo_ = mm.embeddable(ContactInfo.class);
EntityType<Phone> phone_ = mm.entity(Phone.class);
EmbeddableType<Address> addr_ = mm.embeddable(Address.class);

CriteriaQuery<Vendor> q = cb.createQuery(Vendor.class);
Root<Employee> emp = q.from(Employee.class);
Join<Employee, ContactInfo> cinfo =
    emp.join(emp_.getSingularAttribute("contactInfo", ContactInfo.class));
Join<ContactInfo, Phone> p =
    cinfo.join(cinfo_.getSingularAttribute("phones", Phone.class));
q.where(
    cb.equal(emp.get(emp_.getSingularAttribute("contactInfo", ContactInfo.class))
        .get(cinfo_.getSingularAttribute("address", Address.class))
        .get(addr_.getSingularAttribute("zipcode", String.class)), "95054"))
    .select(p.get(phone_.getSingularAttribute("vendor",Vendor.class)));

Example 2:

EntityManager em = ...;
Metamodel mm = em.getMetamodel();

EntityType<Item> item_ = mm.entity(Item.class);
CriteriaQuery<Tuple> q = cb.createTupleQuery();
Root<Item> item = q.from(Item.class);
MapJoin<Item, String, Object> photo =
    item.join(item_.getMap("photos", String.class, Object.class));
q.multiselect(
    item.get(item_.getSingularAttribute("name", String.class)), photo)
        .where(cb.like(photo.key(), "%egret%"));

6.5. Use of the Criteria API with Strings to Reference Attributes

The Criteria API provides the option of specifying the attribute references used in joins and navigation by attribute names used as arguments to the various join, fetch, and get methods.

The resulting queries have the same semantics as described in Section 6.3, but do not provide the same level of type safety.

The examples in this section illustrate this approach. These examples are derived from among those of sections Section 6.3.3 and Section 6.3.5.

Example 1:

CriteriaBuilder cb = ...
CriteriaQuery<String> q = cb.createQuery(String.class);
Root<Customer> cust = q.from(Customer.class);
Join<Order, Item> item = cust.join("orders").join("lineItems");
q.select(cust.<String>get("name"))
    .where(cb.equal(item.get("product").get("productType"), "printer"));

This query is equivalent to the following Jakarta Persistence query language query:

SELECT c.name
FROM Customer c JOIN c.orders o JOIN o.lineItems i
WHERE i.product.productType = 'printer'

It is not required that type parameters be used. However, their omission may result in compiler warnings, as with the below version of the same query:

CriteriaBuilder cb = ...
CriteriaQuery q = cb.createQuery();
Root cust = q.from(Customer.class);
Join item = cust.join("orders").join("lineItems");
q.select(cust.get("name")).where(
    cb.equal(item.get("product").get("productType"),"printer"));

Example 2:

The following query uses an outer join:

CriteriaQuery<Customer> q = cb.createQuery(Customer.class);
Root<Customer> cust = q.from(Customer.class);
Join<Customer,Order> order = cust.join("orders", JoinType.LEFT);
q.where(cb.equal(cust.get("status"), 1))
    .select(cust);

This query is equivalent to the following Jakarta Persistence query language query:

SELECT c FROM Customer c LEFT JOIN c.orders o
WHERE c.status = 1

Example 3:

In the following example, ContactInfo is an embeddable class consisting of an address and set of phones. Phone is an entity.

CriteriaQuery<Vendor> q = cb.createQuery(Vendor.class);
Root<Employee> emp = q.from(Employee.class);
Join<ContactInfo, Phone> phone = emp.join("contactInfo").join("phones");
q.where(cb.equal(emp.get("contactInfo")
    .get("address")
    .get("zipcode"), "95054"));
q.select(phone.<Vendor>get("vendor"));

The following Jakarta Persistence query language query is equivalent:

SELECT p.vendor
FROM Employee e JOIN e.contactInfo.phones p
WHERE e.contactInfo.address.zipcode = '95054'

Example 4:

In this example, the photos attribute corresponds to a map from photo label to filename. The map key is a string, the value an object.

CriteriaQuery<Object> q = cb.createQuery();
Root<Item> item = q.from(Item.class);
MapJoin<Item, String, Object> photo = item.joinMap("photos");
q.multiselect(item.get("name"), photo)
    .where(cb.like(photo.key(), "%egret%"));

This query is equivalent to the following Jakarta Persistence query language query:

SELECT i.name, p
FROM Item i JOIN i.photos p
WHERE KEY(p) LIKE '%egret%'

6.6. Query Modification

A CriteriaQuery, CriteriaUpdate, or CriteriaDelete object may be modified, either before or after Query or TypedQuery objects have been created and executed from it. For example, such modification may entail replacement of the where predicate or the select list. Modifications may thus result in the same query object “base” being reused for several query instances.

For example, the user might create and execute a query from the following CriteriaQuery object:

CriteriaQuery<Customer> q = cb.createQuery(Customer.class);
Root<Customer> c = q.from(Customer.class);

Predicate pred = cb.equal(c.get(Customer_.address).get(Address_.city),"Chicago");

q.select(c);
q.where(pred);

The CriteriaQuery object might then be modified to reflect a different predicate condition, for example:

Predicate pred2 = cb.gt(c.get(Customer_.balanceOwed), 1000);
q.where(pred2);

Note, however, that query elements—-in this example, predicate conditions—are dependent on the CriteriaQuery, CriteriaUpdate, or CriteriaDelete instance, and are thus not portably reusable with different instances.

6.7. Query Execution

A criteria query is executed by passing the CriteriaQuery, CriteriaUpdate, or CriteriaDelete object to the createQuery method of the EntityManager interface to create an executable TypedQuery object (or, in the case of CriteriaUpdate and CriteriaDelete, a Query object), which can then be passed to one of the query execution methods of the TypedQuery or Query interface.

A CriteriaQuery, CriteriaUpdate, or CriteriaDelete object may be further modified after an executable query object has been created from it. The modification of the CriteriaQuery, CriteriaUpdate, or CriteriaDelete object does not have any impact on the already created executable query object. If the modified CriteriaQuery, CriteriaUpdate, or CriteriaDelete object is passed to the createQuery method, the persistence provider must insure that a new executable query object is created and returned that reflects the semantics of the changed query definition.

CriteriaQuery, CriteriaUpdate, and CriteriaDelete objects must be serializable. A persistence vendor is required to support the subsequent deserialization of such an object into a separate JVM instance of that vendor’s runtime, where both runtime instances have access to any required vendor implementation classes. CriteriaQuery, CriteriaUpdate, and CriteriaDelete objects are not required to be interoperable across vendors.

7. Entity Managers and Persistence Contexts

7.1. Persistence Contexts

A persistence context is a set of managed entity instances in which for any persistent entity identity there is a unique entity instance. Within the persistence context, the entity instances and their lifecycle are managed by the entity manager.

In Jakarta EE environments, a JTA transaction typically involves calls across multiple components. Such components may often need to access the same persistence context within a single transaction. To facilitate such use of entity managers in Jakarta EE environments, when an entity manager is injected into a component or looked up directly in the JNDI naming context, its persistence context will automatically be propagated with the current JTA transaction, and the EntityManager references that are mapped to the same persistence unit will provide access to this same persistence context within the JTA transaction. This propagation of persistence contexts by the Jakarta EE container avoids the need for the application to pass references to EntityManager instances from one component to another. An entity manager for which the container manages the persistence context in this manner is termed a container-managed entity manager. A container-managed entity manager’s lifecycle is managed by the Jakarta EE container.

In less common use cases within Jakarta EE environments, applications may need to access a persistence context that is “stand-alone”—i.e. not propagated along with the JTA transaction across the EntityManager references for the given persistence unit. Instead, each instance of creating an entity manager causes a new isolated persistence context to be created that is not accessible through other EntityManager references within the same transaction. These use cases are supported through the createEntityManager methods of the EntityManagerFactory interface. An entity manager that is used by the application to create and destroy a persistence context in this manner is termed an application-managed entity manager. An application-managed entity manager’s lifecycle is managed by the application.

Both container-managed entity managers and application-managed entity managers and their persistence contexts are required to be supported in Jakarta EE web containers and EJB containers. Within an EJB environment, container-managed entity managers are typically used.

In Java SE environments and in Jakarta EE application client containers, only application-managed entity managers are required to be [87].

7.2. Obtaining an EntityManager

The entity manager for a persistence context is obtained from an entity manager factory.

When container-managed entity managers are used (in Jakarta EE environments), the application does not interact with the entity manager factory. The entity managers are obtained directly through dependency injection or from JNDI, and the container manages interaction with the entity manager factory transparently to the application.

When application-managed entity managers are used, the application must use the entity manager factory to manage the entity manager and persistence context lifecycle.

An entity manager must not be shared among multiple concurrently executing threads, as the entity manager and persistence context are not required to be threadsafe. Entity managers must only be accessed in a single-threaded manner.

7.2.1. Obtaining an Entity Manager in the Jakarta EE Environment

A container-managed entity manager is obtained by the application through dependency injection or through direct lookup of the entity manager in the JNDI namespace. The container manages the persistence context lifecycle and the creation and the closing of the entity manager instance transparently to the application.

The PersistenceContext annotation is used for entity manager injection. The type element specifies whether a transaction-scoped or extended persistence context is to be used, as described in Section 7.7. The synchronization element specifies whether the persistence context is always automatically joined to the current transaction (the default) or is not joined to the current transaction unless the joinTransaction method is invoked by the application. The unitName element may optionally be specified to designate the persistence unit whose entity manager factory is used by the container. The semantics of the persistence context synchronization type are further described in Section 7.7.1. Section Section 10.5.2 provides further information about the unitName element.

For example,

@PersistenceContext
EntityManager em;

@PersistenceContext(type=PersistenceContextType.EXTENDED)
EntityManager orderEM;

The JNDI lookup of an entity manager is illustrated below:

@Stateless
@PersistenceContext(name="OrderEM")
public class MySessionBean implements MyInterface {
    @Resource
    SessionContext ctx;

    public void doSomething() {
        EntityManager em = (EntityManager)ctx.lookup("OrderEM");

        // ...
    }
}

7.2.2. Obtaining an Application-managed Entity Manager

An application-managed entity manager is obtained by the application from an entity manager factory.

The EntityManagerFactory API used to obtain an application-managed entity manager is the same independent of whether this API is used in Jakarta EE or Java SE environments.

7.3. Obtaining an Entity Manager Factory

The EntityManagerFactory interface is used by the application to create an application-managed entity manager[88].

Each entity manager factory provides entity manager instances that are all configured in the same manner (e.g., configured to connect to the same database, use the same initial settings as defined by the implementation, etc.)

More than one entity manager factory instance may be available simultaneously in the JVM.[89]

Methods of the EntityManagerFactory interface are threadsafe.

7.3.1. Obtaining an Entity Manager Factory in a Jakarta EE Container

Within a Jakarta EE environment, an entity manager factory can be injected using the PersistenceUnit annotation or obtained through JNDI lookup. The unitName element may optionally be specified to designate the persistence unit whose entity manager factory is used. (See Section 10.5.2).

For example,

@PersistenceUnit
EntityManagerFactory emf;

7.3.2. Obtaining an Entity Manager Factory in a Java SE Environment

Outside a Jakarta EE container environment, the jakarta.persistence.Persistence class is the bootstrap class that provides access to an entity manager factory. The application creates an entity manager factory by calling the createEntityManagerFactory method of the jakarta.persistence.Persistence class, described in Section 9.7.

For example,

EntityManagerFactory emf =
    jakarta.persistence.Persistence.createEntityManagerFactory("Order");
EntityManager em = emf.createEntityManager();

7.3.3. Obtaining an Entity Manager Factory for a programmatically-defined persistence unit

The class jakarta.persistence.PersistenceConfiguration described in Section 9.8 may be used to programmatically define and configure a persistence unit (see Section 8.1), as an alternative to packaging a persistence.xml file, mapping files, and classes inside an archive as described in Section 8.2.

An EntityManagerFactory may be obtained directly from the PersistenceConfiguration.

For example,

DataSource datasource = (DataSource)
        new InitialContext()
                .lookup("java:global/jdbc/MyOrderDB");
EntityManagerFactory emf =
        new PersistenceConfiguration()
                .name("OrderManagement")
                .jtaDataSource(datasource)
                .mappingFile("ormap.xml")
                .managedClass(Order.class)
                .managedClass(Customer.class)
                .createEntityManagerFactory();

7.4. EntityManagerFactory Interface

The EntityManagerFactory interface found in Section B.3

An EntityManagerFactory may be used by the application to obtain an application-managed entity manager. When the application has finished using the entity manager factory, and/or at application shutdown, the application should close the entity manager factory. Once an entity manager factory has been closed, all its entity managers are considered to be in the closed state.

An EntityManagerFactory also provides access to information and services that are global to the persistence unit. This includes access to the second level cache that is maintained by the persistence provider and to the PersistenceUnitUtil interface. The Cache interface is described in Section 3.10.3; the PersistenceUnitUtil interface in Section 7.11.

Any number of vendor-specific properties may be included in the map passed to the createEntityManager methods. Properties that are not recognized by a vendor must be ignored.

Note that the policies of the installation environment may restrict some information from being made available through the EntityManagerFactory getProperties method (for example, JDBC user, password, URL).

Vendors should use vendor namespaces for properties (e.g., com.acme.persistence.logging). Entries that make use of the namespace jakarta.persistence and its subnamespaces must not be used for vendor-specific information. The namespace jakarta.persistence is reserved for use by this specification.

7.5. Controlling Transactions

Depending on the transactional type of the entity manager, transactions involving EntityManager operations may be controlled either through JTA or through use of the resource-local EntityTransaction API, which is mapped to a resource transaction over the resource that underlies the entities managed by the entity manager.

An entity manager whose underlying transactions are controlled through JTA is termed a JTA entity manager.

An entity manager whose underlying transactions are controlled by the application through the EntityTransaction API is termed a resource-local entity manager.

A container-managed entity manager must be a JTA entity manager. JTA entity managers are only specified for use in Jakarta EE containers.

An application-managed entity manager may be either a JTA entity manager or a resource-local entity manager.

An entity manager is defined to be of a given transactional type—either JTA or resource-local—at the time its underlying entity manager factory is configured and created. See sections Section 8.2.1.2 and Section 9.1.

Both JTA entity managers and resource-local entity managers are required to be supported in Jakarta EE web containers and EJB containers. Within an EJB environment, a JTA entity manager is typically used. In general, in Java SE environments only resource-local entity managers are supported.

7.5.1. JTA EntityManagers

An entity manager whose transactions are controlled through JTA is a JTA entity manager. In general, a JTA entity manager participates in the current JTA transaction, which is begun and committed external to the entity manager and propagated to the underlying resource manager.

7.5.2. Resource-local EntityManagers

An entity manager whose transactions are controlled by the application through the EntityTransaction API is a resource-local entity manager. A resource-local entity manager transaction is mapped to a resource transaction over the resource by the persistence provider. Resource-local entity managers may use server or local resources to connect to the database and are unaware of the presence of JTA transactions that may or may not be active.

7.5.3. The EntityTransaction Interface

The EntityTransaction interface found in Section B.2 is used to control resource transactions on resource-local entity managers. The getTransaction() method of EntityManager returns an instance of the EntityTransaction interface.

When a resource-local entity manager is used, and the persistence provider runtime throws an exception defined to cause transaction rollback, the persistence provider must mark the transaction for rollback.

If the EntityTransaction.commit operation fails, the persistence provider must roll back the transaction.

The following example illustrates the creation of an entity manager factory in a Java SE environment, and its use in creating and using a resource-local entity manager.

import jakarta.persistence.*;

public class PasswordChanger {
    public static void main (String[] args) {
        EntityManagerFactory emf =
            Persistence.createEntityManagerFactory("Order");
        EntityManager em = emf.createEntityManager();
        em.getTransaction().begin();

        User user = em.createQuery
            ("SELECT u FROM User u WHERE u.name=:name AND u.pass=:pass", User.class)
            .setParameter("name", args[0])
            .setParameter("pass", args[1])
            .getSingleResult();

        user.setPassword(args[2]);

        em.getTransaction().commit();
        em.close();
        emf.close();
    }
}

7.6. The runInTransaction and callInTransaction methods

The runInTransaction and callInTransaction methods of the EntityManagerFactory provide a shortcut for persistence context and transaction management with an application-managed EntityManager.

entityManagerFactory.runInTransaction(entityManager -> {
    User user = em.createQuery
        ("SELECT u FROM User u WHERE u.name=:name AND u.pass=:pass", User.class)
        .setParameter("name", args[0])
        .setParameter("pass", args[1])
        .getSingleResult();

    user.setPassword(args[2]);
})

The argument function passed to runInTransaction or callInTransaction must be called and passed a new instance of EntityManager. When the argument function returns or throws an exception, this EntityManager must be closed before runInTransaction or callInTransaction returns.

The argument function is executed in the context of a transaction associated with this new EntityManager.

  • If the transaction type of the persistence unit is JTA, and there is a JTA transaction already associated with the caller, then the EntityManager is associated with this current transaction. If the argument function throws an exception, the JTA transaction must be marked for rollback, and the exception must be rethrown by runInTransaction or callInTransaction. Otherwise, callInTransaction must return the same value returned by the argument function.

  • Otherwise, if the transaction type of the persistence unit is resource-local, or if there is no JTA transaction already associated with the caller, then the EntityManager is associated with a new transaction. If the argument function throws an exception, this transaction must be rolled back, and then the exception must be rethrown by runInTransaction or callInTransaction. If the argument function returns, then runInTransaction or callInTransaction must attempt to commit the transaction. If the attempt to commit the transaction fails, the exception must be rethrown. Otherwise, callInTransaction must return the same value returned by the argument function.

The application should not attempt to manage the lifecycle of the transaction or EntityManager directly. If the application calls an operation of EntityTransaction from within a call to runInTransaction or callInTransaction, the behavior is undefined.

7.7. Container-managed Persistence Contexts

When a container-managed entity manager is used, the lifecycle of the persistence context is always managed automatically, transparently to the application, and the persistence context is propagated with the JTA transaction.

A container-managed persistence context may be defined to have either a lifetime that is scoped to a single transaction or an extended lifetime that spans multiple transactions, depending on the PersistenceContextType that is specified when its entity manager is created. This specification refers to such persistence contexts as transaction-scoped persistence contexts and extended persistence contexts respectively.

The lifetime of the persistence context is declared using the PersistenceContext annotation or the persistence-context-ref deployment descriptor element. By default, a transaction-scoped persistence context is used.

Sections Section 7.7.2 and Section 7.7.3 describe transaction-scoped and extended persistence contexts in the absence of persistence context propagation. Persistence context propagation is described in Section 7.7.4.

Persistence contexts are always associated with an entity manager factory. In the following sections, “the persistence context” should be understood to mean “the persistence context associated with a particular entity manager factory”.

7.7.1. Persistence Context Synchronization Type

By default, a container-managed persistence context is of type SynchronizationType.SYNCHRONIZED. Such a persistence context is automatically joined to the current JTA transaction, and updates made to the persistence context are propagated to the underlying resource manager.

A container-managed persistence context may be specified to be of type SynchronizationType.UNSYNCHRONIZED. A persistence context of type SynchronizationType.UNSYNCHRONIZED is not enlisted in any JTA transaction unless explicitly joined to that transaction by the application. A persistence context of type SynchronizationType.UNSYNCHRONIZED is enlisted in a JTA transaction and registered for subsequent transaction notifications against that transaction by the invocation of the EntityManager joinTransaction method. The persistence context remains joined to the transaction until the transaction commits or rolls back. After the transaction commits or rolls back, the persistence context will not be joined to any subsequent transaction unless the joinTransaction method is invoked in the scope of that subsequent transaction.

A persistence context of type SynchronizationType.UNSYNCHRONIZED must not be flushed to the database unless it is joined to a transaction. The application’s use of queries with pessimistic locks, bulk update or delete queries, etc. result in the provider throwing the TransactionRequiredException. After the persistence context has been joined to the JTA transaction, these operations are again allowed.

The application is permitted to invoke the persist, merge, remove, and refresh entity lifecycle operations on an entity manager of type SynchronizationType.UNSYNCHRONIZED independent of whether the persistence context is joined to the current transaction. After the persistence context has been joined to a transaction, changes in a persistence context can be flushed to the database either explicitly by the application or by the provider. If the flush method is not explicitly invoked, the persistence provider may defer flushing until commit time depending on the operations invoked and the flush mode setting in effect.

If an extended persistence context of type SynchronizationType.UNSYNCHRONIZED has not been joined to the current JTA transaction, rollback of the JTA transaction will have no effect upon the persistence context. In general, it is recommended that a non-JTA datasource be specified for use by the persistence provider for a persistence context of type SynchronizationType.UNSYNCHRONIZED that has not been joined to a JTA transaction in order to alleviate the risk of integrating uncommitted changes into the persistence context in the event that the transaction is later rolled back.

If a persistence context of type SynchronizationType.UNSYNCHRONIZED has been joined to the JTA transaction, transaction rollback will cause the persistence context to be cleared and all pre-existing managed and removed instances to become detached. (See Section 3.4.3.)

When a JTA transaction exists, a persistence context of type SynchronizationType.UNSYNCHRONIZED is propagated with that transaction according to the rules in Section 7.7.4.1 regardless of whether the persistence context has been joined to that transaction.

7.7.2. Container-managed Transaction-scoped Persistence Context

The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.

A new persistence context begins when the container-managed entity manager is invoked[90] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.

The persistence context ends when the associated JTA transaction commits or rolls back, and all entities that were managed by the EntityManager become detached.[91]

If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will immediately become detached at the end of the method call.

7.7.3. Container-managed Extended Persistence Context

A container-managed extended persistence context can only be initiated within the scope of a stateful session bean. It exists from the point at which the stateful session bean that declares a dependency on an entity manager of type PersistenceContextType.EXTENDED is created, and is said to be bound to the stateful session bean. The dependency on the extended persistence context is declared by means of the PersistenceContext annotation or persistence-context-ref deployment descriptor element. The association of the extended persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.

The persistence context is closed by the container when the @Remove method of the stateful session bean completes (or the stateful session bean instance is otherwise destroyed).

7.7.3.1. Inheritance of Extended Persistence Context

If a stateful session bean instantiates a stateful session bean (executing in the same EJB container instance) which also has such an extended persistence context with the same synchronization type, the extended persistence context of the first stateful session bean is inherited by the second stateful session bean and bound to it, and this rule recursively applies—independently of whether transactions are active or not at the point of the creation of the stateful session beans. If the stateful session beans differ in declared synchronization type, the EJBException is thrown by the container.

If the persistence context has been inherited by any stateful session beans, the container does not close the persistence context until all such stateful session beans have been removed or otherwise destroyed.

7.7.4. Persistence Context Propagation

As described in Section 7.1, a single persistence context may correspond to one or more JTA entity manager instances (all associated with the same entity manager factory[92]).

The persistence context is propagated across the entity manager instances as the JTA transaction is propagated. A persistence context of type SynchronizationType.UNSYNCHRONIZED is propagated with the JTA transaction regardless of whether it has been joined to the transaction.

Propagation of persistence contexts only applies within a local environment. Persistence contexts are not propagated to remote tiers.

7.7.4.1. Requirements for Persistence Context Propagation

Persistence contexts are propagated by the container across component invocations as follows.

If a component is called and there is no JTA transaction or the JTA transaction is not propagated, the persistence context is not propagated.

  • If an entity manager is then invoked from within the component:

    • Invocation of an entity manager defined with PersistenceContextType.TRANSACTION will result in use of a new persistence context (as described in Section 7.7.2).

    • Invocation of an entity manager defined with PersistenceContextType.EXTENDED will result in the use of the existing extended persistence context bound to that component.

    • If the entity manager is invoked within a JTA transaction, the persistence context will be associated with the JTA transaction.

If a component is called and the JTA transaction is propagated into that component:

  • If the component is a stateful session bean to which an extended persistence context has been bound and there is a different persistence context associated with the JTA transaction, an EJBException is thrown by the container.

  • If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container.

  • Otherwise, if there is a persistence context associated with the JTA transaction, that persistence context is propagated and used.

Note that a component with a persistence context of type SynchronizationType.UNSYNCHRONIZED may be called by a component propagating either a persistence context of type SynchronizationType.UNSYNCHRONIZED or a persistence context of type SynchronizationType.SYNCHRONIZED into it.

The following example shows a container-managed, transaction-scoped persistence context:

@Stateless
public class ShoppingCartImpl implements ShoppingCart {
    @PersistenceContext
    EntityManager em;

    public Order getOrder(Long id) {
        Order order = em.find(Order.class, id);
        order.getLineItems();
        return order;
    }

    public Product getProduct(String name) {
        return (Product) em.createQuery("select p from Product p where p.name = : name")
               .setParameter("name", name)
               .getSingleResult();
    }

    public LineItem createLineItem(Order order, Product product, int quantity) {
        LineItem li = new LineItem(order, product, quantity);
        order.getLineItems().add(li);
        em.persist(li);
        return li;
    }
}

This example shows a container-managed extended persistence context:

/*
 * An extended transaction context is used. The entities remain
 * managed in the persistence context across multiple transactions.
 */
@Stateful
@Transaction(REQUIRES_NEW)
public class ShoppingCartImpl implements ShoppingCart {
    @PersistenceContext(type = EXTENDED)
    EntityManager em;

    private Order order;
    private Product product;

    public void initOrder(Long id) {
        order = em.find(Order.class, id);
    }

    public void initProduct(String name) {
        product = (Product) em.createQuery("select p from Product p where p.name = : name")
                  .setParameter("name", name)
                  .getSingleResult();
    }

    public LineItem createLineItem(int quantity) {
        LineItem li = new LineItem(order, product, quantity);
        order.getLineItems().add(li);
        em.persist(li);
        return li;
    }
}

7.8. Application-managed Persistence Contexts

When an application-managed entity manager is used, the application interacts directly with the persistence provider’s entity manager factory to manage the entity manager lifecycle and to obtain and destroy persistence contexts.

All such application-managed persistence contexts are extended in scope, and can span multiple transactions.

The EntityManagerFactory . createEntityManager method and the EntityManager close and isOpen methods are used to manage the lifecycle of an application-managed entity manager and its associated persistence context.

The extended persistence context exists from the point at which the entity manager has been created using EntityManagerFactory.createEntityManager until the entity manager is closed by means of EntityManager.close.

An extended persistence context obtained from the application-managed entity manager is a stand-alone persistence context—it is not propagated with the transaction.

When a JTA application-managed entity manager is used, an application-managed persistence context may be specified to be of type SynchronizationType.UNSYNCHRONIZED. A persistence context of type SynchronizationType.UNSYNCHRONIZED is not enlisted in any JTA transaction unless explicitly joined to that transaction by the application. A persistence context of type SynchronizationType.UNSYNCHRONIZED is enlisted in a JTA transaction and registered for subsequent transaction notifications against that transaction by the invocation of the EntityManager joinTransaction method. The persistence context remains joined to the transaction until the transaction commits or rolls back. After the transaction commits or rolls back, the persistence context will not be joined to any subsequent transaction unless the joinTransaction method is invoked in the scope of that subsequent transaction.

When a JTA application-managed entity manager is used, if the entity manager is created outside the scope of the current JTA transaction, it is the responsibility of the application to join the entity manager to the transaction (if desired) by calling EntityManager.joinTransaction. If the entity manager is created outside the scope of a JTA transaction, it is not joined to the transaction unless EntityManager.joinTransaction is called.

The EntityManager.close method closes an entity manager to release its persistence context and other resources. After calling close, the application must not invoke any further methods on the EntityManager instance except for getTransaction and isOpen, or the IllegalStateException will be thrown. If the close method is invoked when a transaction is active, the persistence context remains managed until the transaction completes.

The EntityManager.isOpen method indicates whether the entity manager is open. The isOpen method returns true until the entity manager has been closed.

This example shows an application-managed persistence context used in a stateless session bean:

/*
 * Container-managed transaction demarcation is used.
 * The session bean creates and closes an entity manager
 * in each business method.
 */
@Stateless
public class ShoppingCartImpl implements ShoppingCart {
    @PersistenceUnit
    private EntityManagerFactory emf;

    public Order getOrder(Long id) {
        EntityManager em = emf.createEntityManager();
        Order order = em.find(Order.class, id);
        order.getLineItems();
        em.close();
        return order;
    }

    public Product getProduct() {
        EntityManager em = emf.createEntityManager();
        Product product = (Product)
                          em.createQuery("select p from Product p where p.name = :name")
                          .setParameter("name", name)
                          .getSingleResult();
        em.close();
        return product;
    }

    public LineItem createLineItem(Order order, Product product, int quantity) {
        EntityManager em = emf.createEntityManager();
        LineItem li = new LineItem(order, product, quantity);
        order.getLineItems().add(li);
        em.persist(li);
        em.close();
        return li; // remains managed until JTA transaction ends
    }
}

This examples shows an application-managed persistence context used in a stateless session bean:

/*
 * Container-managed transaction demarcation is used.
 * The session bean creates entity manager in PostConstruct
 * method and clears persistence context at the end of each
 * business method.
 */
@Stateless
public class ShoppingCartImpl implements ShoppingCart {
    @PersistenceUnit
    private EntityManagerFactory emf;

    private EntityManager em;

    @PostConstruct
    public void init() {
        em = emf.createEntityManager();
    }

    public Order getOrder(Long id) {
        Order order = em.find(Order.class, id);
        order.getLineItems();
        em.clear(); // entities are detached
        return order;
    }

    public Product getProduct() {
        Product product = (Product)
                          em.createQuery("select p from Product p where p.name = :name")
                          .setParameter("name", name)
                          .getSingleResult();
        em.clear();
        return product;
    }

    public LineItem createLineItem(Order order, Product product, int quantity) {
        em.joinTransaction();
        LineItem li = new LineItem(order, product, quantity);
        order.getLineItems().add(li);
        em.persist(li);
        // persistence context is flushed to database;
        // all updates will be committed to database on tx commit
        em.flush();
        // entities in persistence context are detached
        em.clear();
        return li;
    }

    @PreDestroy
    public void destroy() {
        em.close();
    }
}

This example shows an application-managed persistence context used in a stateful session bean:

/*
 * Container-managed transaction demarcation is used.
 * Entities remain managed until the entity manager is closed.
 */
@Stateful
public class ShoppingCartImpl implements ShoppingCart {
    @PersistenceUnit
    private EntityManagerFactory emf;

    private EntityManager em;

    private Order order;

    private Product product;

    @PostConstruct
    public void init() {
        em = emf.createEntityManager();
    }

    public void initOrder(Long id) {
        order = em.find(Order.class, id);
    }

    public void initProduct(String name) {
        product = (Product) em.createQuery("select p from Product p where p.name = : name")
                  .setParameter("name", name)
                  .getSingleResult();
    }

    public LineItem createLineItem(int quantity) {
        em.joinTransaction();
        LineItem li = new LineItem(order, product, quantity);
        order.getLineItems().add(li);
        em.persist(li);
        return li;
    }

    @Remove
    public void destroy() {
        em.close();
    }
}

Finally, this example shows an application-managed persistence context used with a resource transaction:

// Usage in an ordinary Java class
public class ShoppingImpl {
    private EntityManager em;
    private EntityManagerFactory emf;

    public ShoppingCart() {
        emf = Persistence.createEntityManagerFactory("orderMgt");
        em = emf.createEntityManager();
    }

    private Order order;
    private Product product;

    public void initOrder(Long id) {
        order = em.find(Order.class, id);
    }

    public void initProduct(String name) {
        product = (Product) em.createQuery("select p from Product p where p.name = : name")
                  .setParameter("name", name)
                  .getSingleResult();
    }

    public LineItem createLineItem(int quantity) {
        em.getTransaction().begin();
        LineItem li = new LineItem(order, product, quantity);
        order.getLineItems().add(li);
        em.persist(li);
        em.getTransaction().commit();
        return li;
    }

    public void destroy() {
        em.close();
        emf.close();
    }
}

7.9. Requirements on the Container

7.9.1. Application-managed Persistence Contexts

When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).

7.9.2. Container Managed Persistence Contexts

The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI.

When operating with a third-party persistence provider, the container uses the contracts defined in Section 7.10 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined.

If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in Section 7.7.4.

7.10. Runtime Contracts between the Container and Persistence Provider

This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts.[93]

7.10.1. Container Responsibilities

For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:

  • The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.

  • After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [94] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.

The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.

For stateful session beans with extended persistence contexts:

  • The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See Section 7.7.3).

  • The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.

  • When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.

  • When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.

The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.

When the container creates an entity manager, it may pass a map of properties to the persistence provider by using the EntityManagerFactory.createEntityManager(Map map) method. If properties have been specified in the PersistenceContext annotation or the persistence-context-ref deployment descriptor element, this method must be used and the map must include the specified properties.

If the application invokes EntityManager.unwrap(Class<T> cls), and the container cannot satisfy the request, the container must delegate the unwrap invocation to the provider’s entity manager instance.

7.10.2. Provider Responsibilities

The Provider has no knowledge of the distinction between transaction-scoped and extended persistence contexts. It provides entity managers to the container when requested and registers for transaction synchronization notifications.

  • When EntityManagerFactory.createEntityManager is invoked, the provider must create and return a new entity manager. If a JTA transaction is active and the persistence context is of type SynchronizationType.SYNCHRONIZED, the provider must register for synchronization notifications against the JTA transaction.

  • When EntityManager.joinTransaction is invoked, the provider must register for synchronization notifications against the current JTA transaction if a previous joinTransaction invocation for the transaction has not already been processed.

  • When the JTA transaction commits, if the persistence context is of type SynchronizationType.SYNCHRONIZED or has otherwise been joined to the transaction, the provider must flush all modified entity state to the database.

  • When the JTA transaction rolls back, the provider must detach all managed entities if the persistence context is of type SynchronizationType.SYNCHRONIZED or has otherwise been joined to the transaction. Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the provider should arrange for the managed entities to be detached from the persistence context but not concurrently while the application is in an EntityManager invocation.

  • When the provider throws an exception defined to cause transaction rollback, the provider must mark the transaction for rollback if the persistence context is of type SynchronizationType.SYNCHRONIZED or has otherwise been joined to the transaction.

  • When EntityManager.close is invoked, the provider should release all resources that it may have allocated after any outstanding transactions involving the entity manager have completed. If the entity manager was already in a closed state, the provider must throw the IllegalStateException.

  • When EntityManager.clear is invoked, the provider must detach all managed entities.

7.11. PersistenceUnitUtil Interface

The PersistenceUnitUtil interface found in Section B.20 declares utility methods that can be invoked on entities associated with the persistence unit. The behavior is undefined if these methods are invoked on an entity instance that is not associated with the persistence unit from whose entity manager factory this interface has been obtained.

7.12. SchemaManager Interface

The SchemaManager interface may be found in Section B.16. An instance of SchemaManager may be obtained by calling the getSchemaManager() method of EntityManagerFactory.

The SchemaManager interface allows programmatic control over schema generation and cleanup at runtime. This differs from the functionality described in Section 9.4 which allows schema generation before or during the application deployment and initialization process. Similarly, the generateSchema method described in Section 9.2.1 is intended to be called before the EntityManagerFactory is available. By contrast, an instance of SchemaManager is only available after an EntityManagerFactory has already been created.

For example, SchemaManager is especially useful in tests.

The methods of SchemaManager correspond to values of the property jakarta.persistence.schema-generation.scripts.action. The methods create(), drop(), and validate() correspond to the actions create, drop, and validate. The method truncate() has no corresponding action.

Thus, the behavior of the SchemaManager may be controlled via the properties defined in Section 9.4 and Section 8.2.1.11.

8. Entity Packaging

This chapter describes the packaging of persistence units.

8.1. Persistence Unit

A persistence unit is a logical grouping that includes:

  • an entity manager factory and its entity managers, together with their configuration information,

  • the set of managed classes included in the persistence unit and managed by entity managers created by the entity manager factory, and

  • mapping metadata (in the form of metadata annotations and/or XML metadata) specifying the mapping of these classes to the database.

8.2. Persistence Unit Packaging

Within Jakarta EE environments, any EJB-JAR, WAR, EAR, or application client JAR can define a persistence unit. Any number of persistence units may be defined within these scopes.

A persistence unit may be packaged:

  • within one or more jar files contained within a WAR or EAR,

  • as a set of classes within an EJB-JAR file or in the WAR classes directory, or

  • as a combination of these, as defined below.

A persistence unit is defined by a persistence.xml file. The jar file or directory whose META-INF directory contains the persistence.xml file is termed the root of the persistence unit. In Jakarta EE environments, the root of a persistence unit must be either:

  • an EJB-JAR file,

  • the WEB-INF/classes directory of a WAR file[95],

  • a jar file in the WEB-INF/lib directory of a WAR file,

  • a jar file in the library directory or an EAR, or

  • an application client JAR file.

It is not required that an EJB-JAR or WAR file containing a persistence unit be packaged in an EAR unless the persistence unit contains extra persistence classes in addition to those contained within the EJB-JAR or WAR. See Section 8.2.1.8.

Java Persistence 1.0 supported the use of a jar file in the root of the EAR as the root of a persistence unit. This use is no longer supported. Portable applications should use the EAR library directory for this case instead. See [6].

A persistence unit must have a name. The name of the persistence unit must be unique within a given EJB-JAR file, within a given WAR file, within a given application client JAR, or within an EAR. See Section 8.2.2.

The persistence.xml file may be used to define more than one persistence unit within the same scope.

All persistence classes defined at the level of the Jakarta EE EAR must be accessible to other Jakarta EE components in the application—that is, to all components loaded by the application classloader—such that if the same entity class is referenced by two different Jakarta EE components (which may be using different persistence units), the referenced class is the same identical class.

In Java SE environments, the metadata mapping files, jar files, and classes described in the following sections can be used. To insure the portability of a Java SE application, it is necessary to explicitly list the managed persistence classes included in the persistence unit using the class element of the persistence.xml file. See Section 8.2.1.8.

8.2.1. persistence.xml file

A persistence.xml file defines a persistence unit. The persistence.xml file is located in the META-INF directory of the root of the persistence unit. It may be used to specify:

  • managed persistence classes included in the persistence unit,

  • object/relational mapping information for those classes,

  • scripts for use in schema generation and bulk loading of data, and

  • other configuration information for the persistence unit and for the entity managers and entity manager factory of the persistence unit.

This information may be defined by containment or by reference, as described below.

The object/relational mapping information can take the form of:

  • annotations on the managed persistence classes included in the persistence unit,

  • an orm.xml file contained in the META-INF directory of the root of the persistence unit,

  • one or more XML files accessible on the classpath and referenced from the persistence.xml file, or

  • any combination of the previous options.

The managed persistence classes may be:

  • contained within the root of the persistence unit,

  • specified by reference—that is, by naming the classes, class archives, or XML mapping files (which in turn reference classes) that are accessible on the application classpath, or

  • specified by any combination of these means.

The root element of the persistence.xml file is the persistence element. The persistence element consists of one or more persistence-unit elements.

The persistence-unit element consists of the name and transaction-type attributes and the following sub-elements: description, provider, jta-data-source, non-jta-data-source, mapping-file, jar-file, class, exclude-unlisted-classes, shared-cache-mode, validation-mode, and properties.

The name attribute is required; the other attributes and elements are optional. Their semantics are described in the following subsections.

Examples:

<persistence>
    <persistence-unit name="OrderManagement">
        <description>
            This unit manages orders and customers.
            It does not rely on any vendor-specific features and can
            therefore be deployed to any persistence provider.
        </description>
        <jta-data-source>jdbc/MyOrderDB</jta-data-source>
        <mapping-file>ormap.xml</mapping-file>
        <jar-file>MyOrderApp.jar</jar-file>
        <class>com.widgets.Order</class>
        <class>com.widgets.Customer</class>
    </persistence-unit>
</persistence>
<persistence>
    <persistence-unit name="OrderManagement2">
        <description>
            This unit manages inventory for auto parts.
            It depends on features provided by the
            com.acme.persistence implementation.
        </description>
        <provider>com.acme.AcmePersistence</provider>
        <jta-data-source>jdbc/MyPartDB</jta-data-source>
        <mapping-file>ormap2.xml</mapping-file>
        <jar-file>MyPartsApp.jar</jar-file>
        <properties>
            <property name="com.acme.persistence.sql-logging" value="on"/>
        </properties>
    </persistence-unit>
</persistence>
8.2.1.1. name

The name attribute defines the name of the persistence unit. This name is used to identify the persistence unit referred to by a PersistenceContext or PersistenceUnit annotation and in the programmatic API for creating an entity manager factory.

8.2.1.2. transaction-type

The transaction-type attribute specifies whether entity managers created by the entity manager factory for the persistence unit are JTA entity managers or resource-local entity managers. The value of this element must be JTA or RESOURCE_LOCAL:

  • JTA means that a JTA data source is provided—either as specified by the jta-data-source element, or by the container.

  • In a Jakarta EE environment, RESOURCE_LOCAL usually means that a non-JTA datasource is provided.

Configuration of datasources is described below in Section 8.2.1.7.

If the transaction-type is not explicitly specified, its value is defaulted:

  • in a Jakarta EE environment, the default is JTA, but

  • in a Java SE environment, the default is RESOURCE_LOCAL.

8.2.1.3. description

The description element provides optional descriptive information about the persistence unit.

8.2.1.4. provider

The provider element specifies the name of a provider-specific implementation of jakarta.persistence.spi.PersistenceProvider. The provider element is optional, but should be explicitly specified if the application depends on the use of a particular persistence provider.

8.2.1.5. qualifier

The qualifier element specifies the fully-qualified class name of an annotation annotated jakarta.inject.Qualifier. This qualifier annotation may be used to disambiguate the persistence unit for the purposes of dependency injection.

8.2.1.6. scope

The scope element specifies the fully-qualified class name of an annotation annotated jakarta.inject.Scope or jakarta.enterprise.context.NormalScope. This scope annotation may be used to determine the scope of a persistence context for the purposes of dependency injection.

8.2.1.7. jta-data-source, non-jta-data-source

In Jakarta EE environments:

  • the jta-data-source element specifies the JNDI name of a JTA data source, and/or

  • the non-jta-data-source element specifies the JNDI name of a non-JTA data source.

The specified data source is used by the persistence provider to obtain database connections. If neither element is specified, the deployer must specify a data source at deployment, or a default data source must be provided by the container.

In Java SE environments, these elements may be used, or the data source information may be specified by other means, depending upon the requirements of the provider.

8.2.1.8. mapping-file, jar-file, class, exclude-unlisted-classes

The following classes must be implicitly or explicitly denoted as managed persistence classes to be included within a persistence unit:

  • entity classes;

  • embeddable classes;

  • mapped superclasses;

  • converter classes.

The set of managed persistence classes managed by a persistence unit is specified using one or more of the following:[96]

  • annotated managed persistence classes contained in the root of the persistence unit (unless the exclude-unlisted-classes element is specified);

  • one or more object/relational mapping XML files;

  • one or more JAR files to be searched for classes;

  • an explicit list of classes.

The set of entities managed by the persistence unit is the union of these sources, with the mapping metadata annotations (or annotation defaults) for any given class being overridden by the XML mapping information file if there are both annotations and XML mappings for that class. The minimum portable level of overriding is at the level of the persistent field or property.

The classes and/or jars that named as part of a persistence unit must be on the classpath; referencing them from the persistence.xml file does not cause them to be placed on the classpath.

All classes must be on the classpath to ensure that entity managers from different persistence units that map the same class will be accessing the same identical class.

Annotated Classes in the Root of the Persistence Unit

By default, in the Java EE environment, the root of the persistence unit is searched for annotated managed persistence classes—classes with an Entity, Embeddable, MappedSuperclass, or Converter annotation—and mapping metadata annotations found on these classes are processed. Where mapping annotations are missing, the classes are mapped using mapping annotation defaults.

This behavior is disabled if the exclude-unlisted-classes of the persistence.xml file is specified as true. In this case, an annotated persistence class located in the root of the persistence unit is not included in the persistence unit unless it is explicitly listed in a class element of the persistence.xml file or in a mapping file.

In the Java SE environment, this behavior is not required. Portable Java SE applications should explicitly list each persistence class in a class element of the persistence.xml file or in a mapping file. The exclude-unlisted-classes element is not intended for use in Java SE environments.

Object/relational Mapping Files

An object/relational mapping XML file contains mapping information for the classes it lists.

  • An object/relational mapping XML file named orm.xml may be located in the META-INF directory in the root of the persistence unit or in the META-INF directory of any jar file referenced by the persistence.xml.

  • Alternatively, or in addition, one or more mapping files may be referenced by the mapping-file elements of the persistence-unit element. These mapping files may be present anywhere on the class path.

An orm.xml mapping file or other mapping file is loaded as a resource by the persistence provider. If a mapping file is specified, the classes and mapping information listed in the mapping file are used as described in Chapter 12.

If multiple mapping files are specified (possibly including one or more orm.xml files), the resulting mappings are obtained by combining the mappings from all the files. If multiple mapping files referenced within a single persistence unit (including any orm.xml file) contain overlapping mapping information for a given class, the result is undefined. That is, the object/relational mapping information contained in any given mapping file referenced within the persistence unit must be disjoint at the class level from object/relational mapping information contained in other mapping files referenced within the persistence unit.

Jar Files

One or more JAR files may be specified using jar-file elements instead of, or in addition to, the mapping files listed by the mapping-file elements. These JAR files are searched for managed persistence classes and any mapping metadata annotations found on them are processed. Where mapping annotations are missing, the classes are mapped using the mapping annotation defaults defined by this specification. Such JAR files are specified relative to the directory or jar file that contains the root of the persistence unit.[97]

The following examples illustrate the use of the jar-file element to reference additional persistence classes. These examples make use of the convention that a jar file with a name terminating in “PUnit” contains the persistence.xml file and that a jar file with a name terminating in “Entities” contains additional persistence classes.

Example 1:

app.ear
    lib/earEntities.jar
    earRootPUnit.jar (with META-INF/persistence.xml)

persistence.xml contains:

<jar-file>lib/earEntities.jar</jar-file>

Example 2:

app.ear
    lib/earEntities.jar
    lib/earLibPUnit.jar (with META-INF/persistence.xml)

persistence.xml contains:

<jar-file>earEntities.jar</jar-file>

Example 3:

app.ear
    lib/earEntities.jar
    ejbjar.jar (with META-INF/persistence.xml)

persistence.xml contains:

<jar-file>lib/earEntities.jar</jar-file>

Example 4:

app.ear
    war1.war
        WEB-INF/lib/warEntities.jar
        WEB-INF/lib/warPUnit.jar (with META-INF/persistence.xml)

persistence.xml contains:

<jar-file>warEntities.jar</jar-file>

Example 5:

app.ear
    war2.war
        WEB-INF/lib/warEntities.jar
        WEB-INF/classes/META-INF/persistence.xml

persistence.xml contains:

<jar-file>lib/warEntities.jar</jar-file>

Example 6:

app.ear
    lib/earEntities.jar
    war2.war
        WEB-INF/classes/META-INF/persistence.xml

persistence.xml contains:

<jar-file>../../lib/earEntities.jar</jar-file>

Example 7:

app.ear
    lib/earEntities.jar
    war1.war
        WEB-INF/lib/warPUnit.jar (with META-INF/persistence.xml)

persistence.xml contains:

<jar-file>../../../lib/earEntities.jar</jar-file>
List of Managed Classes

A list of named managed persistence classes—entity classes, embeddable classes, mapped superclasses, and converter classes—may be specified instead of, or in addition to, the listed JAR files and mapping files. Any mapping metadata annotations found on these classes are processed. Where mapping annotations are missing, the classes are mapped using the mapping annotation defaults. The class element is used to list a managed persistence class.

In Java SE environments, an explicit list of all managed persistence class names must be specified to insure portability. Portable Java SE applications should not rely on the other mechanisms described here to determine the managed persistence classes of a persistence unit. In Java SE environments, a persistence provider may require that the set of entity classes and other classes to be managed is fully enumerated in each persistence.xml file.

8.2.1.9. shared-cache-mode

The shared-cache-mode element determines whether second-level caching is in effect for the persistence unit. See Section 3.10.1.

8.2.1.10. validation-mode

The validation-mode element determines whether automatic lifecycle event time validation is in effect. See Section 3.7.1.1.

8.2.1.11. properties

The properties element is used to specify both standard and vendor-specific properties and hints that apply to the persistence unit and its entity manager factory configuration.

The following properties and hints defined by this specification are intended for use in both Jakarta EE and Java SE environments:

jakarta.persistence.lock.timeout

The pessimistic lock timeout in milliseconds. This is a hint only.

jakarta.persistence.query.timeout

The query timeout in milliseconds. This is a hint only.

jakarta.persistence.validation.group.pre-persist

Bean Validation groups that are targeted for validation upon the pre-persist event (overrides the default behavior).

jakarta.persistence.validation.group.pre-update

Bean Validation groups that are targeted for validation upon the pre-update event (overrides the default behavior).

jakarta.persistence.validation.group.pre-remove

Bean Validation groups that are targeted for validation upon the pre-remove event (overrides the default behavior).

The following properties defined by this specification are intended for use in Java SE environments.

jakarta.persistence.jdbc.driver

Fully qualified name of the JDBC driver class.

jakarta.persistence.jdbc.url

Driver-specific connection URL.

jakarta.persistence.jdbc.user

Username for database connection authentication.

jakarta.persistence.jdbc.password

Password for database connection authentication

Scripts for use in schema generation may be specified using the jakarta.persistence.schema-generation.create-script-source and jakarta.persistence.schema-generation.drop-script-source properties. A script to specify SQL for the bulk loading of data may be specified by the jakarta.persistence.sql-load-script-source property. These properties are intended for use in both Jakarta EE and Java SE environments:

jakarta.persistence.schema-generation.create-script-source

Name of a script packaged as part of the persistence application or a string identifying a file URL that designates a script.

jakarta.persistence.schema-generation.drop-script-source

Name of a script packaged as part of the persistence application or a string identifying a file URL that designates a script.

jakarta.persistence.sql-load-script-source

Name of a script packaged as part of the persistence unit or a string identifying a file URL that designates a script.

When scripts are packaged as part of the persistence application, these properties must specify locations relative to the root of the persistence unit. When scripts are provided externally (or when schema generation is configured to write script files, as described below), strings identifying file URLs must be specified. In Jakarta EE environments, such file URLs must be absolute paths. In Jakarta EE environments, all source and target file locations must be accessible to the application server deploying the persistence unit.

In general, it is expected that schema generation will be initiated by means of the APIs described in Section 9.4. However, schema generation actions may also be specified by means of the following properties used in the persistence.xml file.

jakarta.persistence.schema-generation.database.action

The jakarta.persistence.schema-generation.database.action property specifies the action to be taken by the persistence provider with regard to the database artifacts. The values for this property are none, create, drop-and-create, drop, validate. If this property is not specified, it is assumed that schema generation is not needed or will be initiated by other means, and, by default, no schema generation actions will be taken on the database. (See Section 9.4.)

jakarta.persistence.schema-generation.scripts.action

The jakarta.persistence.schema-generation.scripts.action property specifies which scripts are to be generated by the persistence provider. The values for this property are none, create, drop-and-create, drop. A script will only be generated if the script target is specified. If this property is not specified, it is assumed that script generation is not needed or will be initiated by other means, and, by default, no scripts will be generated. (See Section 9.4.)

jakarta.persistence.schema-generation.create-source

The jakarta.persistence.schema-generation.create-source property specifies whether the creation of database artifacts is to occur on the basis of the object/relational mapping metadata, DDL script, or a combination of the two. The values for this property are metadata, script, metadata-then-script, script-then-metadata. If this property is not specified, and a script is specified by the jakarta.persistence.schema-generation.create-script-source property, the script (only) will be used for schema generation; otherwise if this property is not specified, schema generation will occur on the basis of the object/relational mapping metadata (only). The metadata-then-script and script-then-metadata values specify that a combination of metadata and script is to be used and the order in which this use is to occur. If either of these values is specified and the resulting database actions are not disjoint, the results are undefined and schema generation may fail.

jakarta.persistence.schema-generation.drop-source

The jakarta.persistence.schema-generation.drop-source property specifies whether the dropping of database artifacts is to occur on the basis of the object/relational mapping metadata, DDL script, or a combination of the two. The values for this property are metadata, script, metadata-then-script, script-then-metadata. If this property is not specified, and a script is specified by the jakarta.persistence.schema-generation.drop-script-source property, the script (only) will be used for the dropping of database artifacts; otherwise if this property is not specified, the dropping of database artifacts will occur on the basis of the object/relational mapping metadata (only). The metadata-then-script and script-then-metadata values specify that a combination of metadata and script is to be used and the order in which this use is to occur. If either of these values is specified and the resulting database actions are not disjoint, the results are undefined and the dropping of database artifacts may fail.

jakarta.persistence.schema-generation.scripts.create-target,
jakarta.persistence.schema-generation.scripts.drop-target

If scripts are to be generated, the target locations for the writing of these scripts must be specified. These targets are specified as strings corresponding to file URLs.

If a persistence provider does not recognize a property (other than a property defined by this specification), the provider must ignore it.

Vendors should define properties in vendor-specific namespaces, (e.g com.acme.persistence.logging). The namespace jakarta.persistence is reserved for use by this specification, and must not be used to define vendor-specific properties.

The following are sample contents of a persistence.xml file.

Example 1:

<persistence-unit name="OrderManagement"/>

A persistence unit named OrderManagement is created.

Any annotated managed persistence classes found in the root of the persistence unit are added to the list of managed persistence classes. If a META-INF/orm.xml file exists, any classes referenced by it and mapping information contained in it are used as specified above. Because no provider is specified, the persistence unit is assumed to be portable across providers. Because the transaction type is not specified, JTA is assumed for Jakarta EE environments. The container must provide the data source (it may be specified at application deployment, for example). In Java SE environments, the data source may be specified by other means and a transaction type of RESOURCE_LOCAL is assumed.

Example 2:

<persistence-unit name="OrderManagement2">
    <mapping-file>mappings.xml</mapping-file>
</persistence-unit>

A persistence unit named OrderManagement2 is created. Any annotated managed persistence classes found in the root of the persistence unit are added to the list of managed persistence classes. The mappings.xml resource exists on the classpath and any classes and mapping information contained in it are used as specified above. If a META-INF/orm.xml file exists, any classes and mapping information contained in it are used as well. The transaction type, data source, and provider are as described above.

Example 3:

<persistence-unit name="OrderManagement3">
    <jar-file>order.jar</jar-file>
    <jar-file>order-supplemental.jar</jar-file>
</persistence-unit>

A persistence unit named OrderManagement3 is created. Any annotated managed persistence classes found in the root of the persistence unit are added to the list of managed persistence classes. If a META-INF/orm.xml file exists, any classes and mapping information contained in it are used as specified above. The order.jar and order-supplemental.jar files are searched for managed persistence classes and any annotated managed persistence classes found in them and/or any classes specified in the orm.xml files of these jar files are added. The transaction-type, data source and provider are as described above.

Example 4:

<persistence-unit name="OrderManagement4" transaction-type=RESOURCE_LOCAL>
    <non-jta-data-source>java:app/jdbc/MyDB</non-jta-data-source>
    <mapping-file>order-mappings.xml</mapping-file>
    <class>com.acme.Order</class>
    <class>com.acme.Customer</class>
    <class>com.acme.Item</class>
    <exclude-unlisted-classes/>
</persistence-unit>

A persistence unit named OrderManagement4 is created. The file order-mappings.xml is read as a resource and any classes referenced by it and mapping information contained in it are used[98]. The annotated Order, Customer and Item classes are loaded and are added. No (other) classes contained in the root of the persistence unit are added to the list of managed persistence classes. The persistence unit assumed to be portable across providers. A entity manager factory supplying resource-local entity managers will be created. The data source java:app/jdbc/MyDB must be used.

Example 5:

<persistence-unit name="OrderManagement5">
    <provider>com.acme.AcmePersistence</provider>
    <mapping-file>order1.xml</mapping-file>
    <mapping-file>order2.xml</mapping-file>
    <jar-file>order.jar</jar-file>
    <jar-file>order-supplemental.jar</jar-file>
</persistence-unit>

A persistence unit named OrderManagement5 is created. Any annotated managed persistence classes found in the root of the persistence unit are added to the list of managed classes. The order1.xml and order2.xml files are read as resources and any classes referenced by them and mapping information contained in them are also used as specified above. The order.jar is a jar file on the classpath containing another persistence unit, while order-supplemental.jar is just a library of classes. Both of these jar files are searched for annotated managed persistence classes and any annotated managed persistence classes found in them and any classes specified in the orm.xml files (if any) of these jar files are added. The provider com.acme.AcmePersistence must be used.

Note that the persistence.xml file contained in order.jar is not used to augment the persistence unit OrderManagement5 with the classes of the persistence unit whose root is order.jar.

8.2.2. Persistence Unit Scope

An EJB-JAR, WAR, application client JAR, or EAR can define a persistence unit. When referencing a persistence unit using the unitName annotation element or persistence-unit-name deployment descriptor element, the visibility scope of the persistence unit is determined by its point of definition:

  • A persistence unit defined at the level of an EJB-JAR, WAR, or application client JAR is scoped to that EJB-JAR, WAR, or application JAR respectively and is visible to the components defined in that jar or WAR.

  • A persistence unit defined at the level of an EAR is generally visible to all components in the application. However, if a persistence unit of the same name is defined by an EJB-JAR, WAR, or application JAR file within the EAR, the persistence unit of that name defined at EAR level will not be visible to the components defined by that EJB-JAR, WAR, or application JAR file, unless the persistence unit reference uses the persistence unit name # syntax to specify a path name to disambiguate the reference.

The # syntax may be used with both the unitName annotation element or persistence-unit-name deployment descriptor element to reference a persistence unit defined at EAR level.

When the # syntax is used, the path name is interpreted relative to the referencing application component jar file. For example, the syntax ../lib/persistenceUnitRoot.jar#myPersistenceUnit refers to a persistence unit with:

  • name myPersistenceUnit, as specified in the name element of the persistence.xml file, and

  • root given by the relative path name ../lib/persistenceUnitRoot.jar.

8.3. persistence.xml Schema

This section provides the XML schema for the persistence.xml file.

<?xml version="1.0" encoding="UTF-8"?>

<!-- persistence.xml schema -->
<xsd:schema targetNamespace="https://jakarta.ee/xml/ns/persistence"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:persistence="https://jakarta.ee/xml/ns/persistence"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified"
  version="3.2">

   <xsd:annotation>
     <xsd:documentation><![CDATA[

     This is the XML Schema for the persistence configuration file.
     The file must be named "META-INF/persistence.xml" in the
     persistence archive.

     Persistence configuration files must indicate
     the persistence schema by using the persistence namespace:

     https://jakarta.ee/xml/ns/persistence

     and indicate the version of the schema by
     using the version element as shown below:

      <persistence xmlns="https://jakarta.ee/xml/ns/persistence"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="https://jakarta.ee/xml/ns/persistence
          https://jakarta.ee/xml/ns/persistence/persistence_3_2.xsd"
        version="3.2">
          ...
      </persistence>

    ]]></xsd:documentation>
  </xsd:annotation>

  <xsd:simpleType name="versionType">
    <xsd:restriction base="xsd:token">
      <xsd:pattern value="[0-9]+(\.[0-9]+)*"/>
    </xsd:restriction>
  </xsd:simpleType>

  <!-- **************************************************** -->

  <xsd:element name="persistence">
    <xsd:complexType>
      <xsd:sequence>

        <!-- **************************************************** -->

        <xsd:element name="persistence-unit"
                     minOccurs="1" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:annotation>
              <xsd:documentation>

                Configuration of a persistence unit.

              </xsd:documentation>
            </xsd:annotation>
            <xsd:sequence>

            <!-- **************************************************** -->

              <xsd:element name="description" type="xsd:string"
                           minOccurs="0">
                <xsd:annotation>
                  <xsd:documentation>

                    Description of this persistence unit.

                  </xsd:documentation>
                </xsd:annotation>
              </xsd:element>

              <!-- **************************************************** -->

              <xsd:element name="provider" type="xsd:string"
                           minOccurs="0">
                <xsd:annotation>
                  <xsd:documentation>

                    Provider class that supplies EntityManagers for this
                    persistence unit.

                  </xsd:documentation>
                </xsd:annotation>
              </xsd:element>

              <!-- **************************************************** -->

              <xsd:element name="qualifier" type="xsd:string"
                           minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                  <xsd:documentation>

                    Qualifier annotation class used for dependency injection.

                  </xsd:documentation>
                </xsd:annotation>
              </xsd:element>

              <!-- **************************************************** -->

              <xsd:element name="scope" type="xsd:string"
                           minOccurs="0">
                <xsd:annotation>
                  <xsd:documentation>

                    Scope annotation class used for dependency injection.

                  </xsd:documentation>
                </xsd:annotation>
              </xsd:element>

              <!-- **************************************************** -->

              <xsd:element name="jta-data-source" type="xsd:string"
                           minOccurs="0">
                <xsd:annotation>
                  <xsd:documentation>

                    The container-specific name of the JTA datasource to use.

                  </xsd:documentation>
                </xsd:annotation>
              </xsd:element>

              <!-- **************************************************** -->

              <xsd:element name="non-jta-data-source" type="xsd:string"
                           minOccurs="0">
                <xsd:annotation>
                  <xsd:documentation>

                    The container-specific name of a non-JTA datasource to use.

                  </xsd:documentation>
                </xsd:annotation>
              </xsd:element>

              <!-- **************************************************** -->

              <xsd:element name="mapping-file" type="xsd:string"
                           minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                  <xsd:documentation>

                    File containing mapping information. Loaded as a resource
                    by the persistence provider.

                  </xsd:documentation>
                </xsd:annotation>
              </xsd:element>

              <!-- **************************************************** -->

              <xsd:element name="jar-file" type="xsd:string"
                           minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                  <xsd:documentation>

                    Jar file that is to be scanned for managed classes.

                  </xsd:documentation>
                </xsd:annotation>
              </xsd:element>

              <!-- **************************************************** -->

              <xsd:element name="class" type="xsd:string"
                           minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                  <xsd:documentation>

                    Managed class to be included in the persistence unit and
                    to scan for annotations.  It should be annotated
                    with either @Entity, @Embeddable or @MappedSuperclass.

                  </xsd:documentation>
                </xsd:annotation>
              </xsd:element>

              <!-- **************************************************** -->

              <xsd:element name="exclude-unlisted-classes" type="xsd:boolean"
                           default="true" minOccurs="0">
                <xsd:annotation>
                  <xsd:documentation>

                    When set to true then only listed classes and jars will
                    be scanned for persistent classes, otherwise the
                    enclosing jar or directory will also be scanned.
                    Not applicable to Java SE persistence units.

                  </xsd:documentation>
                </xsd:annotation>
              </xsd:element>

              <!-- **************************************************** -->

              <xsd:element name="shared-cache-mode"
                           type="persistence:persistence-unit-caching-type"
                           minOccurs="0">
                <xsd:annotation>
                  <xsd:documentation>

                    Defines whether caching is enabled for the
                    persistence unit if caching is supported by the
                    persistence provider. When set to ALL, all entities
                    will be cached. When set to NONE, no entities will
                    be cached. When set to ENABLE_SELECTIVE, only entities
                    specified as cacheable will be cached. When set to
                    DISABLE_SELECTIVE, entities specified as not cacheable
                    will not be cached. When not specified or when set to
                    UNSPECIFIED, provider defaults may apply.

                  </xsd:documentation>
                </xsd:annotation>
              </xsd:element>

              <!-- **************************************************** -->

              <xsd:element name="validation-mode"
                           type="persistence:persistence-unit-validation-mode-type"
                           minOccurs="0">
                <xsd:annotation>
                  <xsd:documentation>

                    The validation mode to be used for the persistence unit.

                  </xsd:documentation>
                </xsd:annotation>
              </xsd:element>


              <!-- **************************************************** -->

              <xsd:element name="properties" minOccurs="0">
                <xsd:annotation>
                  <xsd:documentation>

                    A list of standard and vendor-specific properties
                    and hints.

                  </xsd:documentation>
                </xsd:annotation>
                <xsd:complexType>
                  <xsd:sequence>
                    <xsd:element name="property"
                                 minOccurs="0" maxOccurs="unbounded">
                      <xsd:annotation>
                        <xsd:documentation>
                          A name-value pair.
                        </xsd:documentation>
                      </xsd:annotation>
                      <xsd:complexType>
                        <xsd:attribute name="name" type="xsd:string"
                                       use="required"/>
                        <xsd:attribute name="value" type="xsd:string"
                                       use="required"/>
                      </xsd:complexType>
                    </xsd:element>
                  </xsd:sequence>
                </xsd:complexType>
              </xsd:element>

              <xsd:any namespace="##other" processContents="lax"
                       minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                  <xsd:documentation>
                    An extension point for integration related configuration, e.g. cdi:
                    <!--
                    <persistence-unit name="my-unit" xmlns:cdi="https://jakarta.ee/xml/ns/persistence-cdi">
                      ...
                      <cdi:scope>com.example.jpa.ACustomScope</cdi:scope>
                      <cdi:qualifier>com.example.jpa.CustomQualifier</cdi:qualifier>
                    </persistence-unit>
                    -->
                  </xsd:documentation>
                </xsd:annotation>
              </xsd:any>
            </xsd:sequence>

            <!-- **************************************************** -->

            <xsd:attribute name="name" type="xsd:string" use="required">
              <xsd:annotation>
                <xsd:documentation>

                  Name used in code to reference this persistence unit.

                </xsd:documentation>
              </xsd:annotation>
            </xsd:attribute>

            <!-- **************************************************** -->

            <xsd:attribute name="transaction-type"
                           type="persistence:persistence-unit-transaction-type">
              <xsd:annotation>
                <xsd:documentation>

                  Type of transactions used by EntityManagers from this
                  persistence unit.

                </xsd:documentation>
              </xsd:annotation>
            </xsd:attribute>

          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
      <xsd:attribute name="version" type="persistence:versionType"
                     fixed="3.2" use="required"/>
    </xsd:complexType>
  </xsd:element>

  <!-- **************************************************** -->

  <xsd:simpleType name="persistence-unit-transaction-type">
    <xsd:annotation>
      <xsd:documentation>

        public enum PersistenceUnitTransactionType {JTA, RESOURCE_LOCAL};

      </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:token">
      <xsd:enumeration value="JTA"/>
      <xsd:enumeration value="RESOURCE_LOCAL"/>
    </xsd:restriction>
  </xsd:simpleType>

<!-- **************************************************** -->

  <xsd:simpleType name="persistence-unit-caching-type">
    <xsd:annotation>
      <xsd:documentation>

        public enum SharedCacheMode { ALL, NONE, ENABLE_SELECTIVE, DISABLE_SELECTIVE, UNSPECIFIED};

      </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:token">
      <xsd:enumeration value="ALL"/>
      <xsd:enumeration value="NONE"/>
      <xsd:enumeration value="ENABLE_SELECTIVE"/>
      <xsd:enumeration value="DISABLE_SELECTIVE"/>
      <xsd:enumeration value="UNSPECIFIED"/>
    </xsd:restriction>
  </xsd:simpleType>

<!-- **************************************************** -->

  <xsd:simpleType name="persistence-unit-validation-mode-type">
    <xsd:annotation>
      <xsd:documentation>

        public enum ValidationMode { AUTO, CALLBACK, NONE};

      </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:token">
      <xsd:enumeration value="AUTO"/>
      <xsd:enumeration value="CALLBACK"/>
      <xsd:enumeration value="NONE"/>
    </xsd:restriction>
  </xsd:simpleType>

</xsd:schema>

9. Container and Provider Contracts for Deployment and Bootstrapping

This chapter defines requirements on the Jakarta EE container and on the persistence provider for deployment and bootstrapping.

9.1. Jakarta EE Deployment

Each persistence unit deployed into a Jakarta EE container consists of a single persistence.xml file, any number of mapping files, and any number of class files.

At deployment time the container is responsible for scanning the locations specified in Section 8.2 and discovering the persistence.xml files and processing them.

When the container finds a persistence.xml file, it must process the persistence unit definitions that it contains. The container must validate the persistence.xml file against the persistence_3_2.xsd, persistence_3_0.xsd or persistence_2_2.xsd schema in accordance with the version specified by the persistence.xml file and report any validation errors. Provider or data source information not specified in the persistence.xml file must be provided at deployment time or defaulted by the container. The container may optionally add any container-specific properties to be passed to the provider when creating the entity manager factory for the persistence unit.

Once the container has read the persistence metadata, it determines the jakarta.persistence.spi.PersistenceProvider implementation class for each deployed named persistence unit. The container then creates an instance of the PersistenceProvider implementation class for each deployed named persistence unit and invokes the createContainerEntityManagerFactory method on that instance.

  • The container must implement the PersistenceUnitInfo interface described in Section 9.6 and pass the metadata—in the form of a PersistenceUnitInfo instance—to the persistence provider as part of this call.

  • If a Bean Validation provider exists in the container environment and the validation-mode NONE is not specified, a ValidatorFactory instance must be made available by the container. The container is responsible for passing this ValidatorFactory instance via the map that is passed as an argument to the createContainerEntityManagerFactory call. The map key used must be the standard property name jakarta.persistence.validation.factory.

  • If CDI is enabled, a BeanManager instance must be made available by the container. The container is responsible for passing this BeanManager instance via the map that is passed as an argument to the createContainerEntityManagerFactory call. The map key used must be the standard property name jakarta.persistence.bean.manager.

The EntityManagerFactory instance obtained as a result will be used by the container to create container-managed entity managers. Only one EntityManagerFactory is permitted to be created for each deployed persistence unit configuration. Any number of EntityManager instances may be created from a given factory.

In a Jakarta EE environment, the classes of the persistence unit should not be loaded by the application class loader or any of its parent class loaders until after the entity manager factory for the persistence unit has been created.

When a persistence unit is redeployed, the container should call the close method on the previous EntityManagerFactory instance and call the createContainerEntityManagerFactory method again, with the required PersistenceUnitInfo metadata, to achieve the redeployment.

9.2. Bootstrapping in Java SE Environments

In Java SE environments, the Persistence.createEntityManagerFactory method is used by the application to create an entity manager factory[99].

A persistence provider implementation running in a Java SE environment should also act as a service provider by supplying a service provider configuration file as defined by the Java SE platform.

The provider configuration file serves to export the provider implementation class to the Persistence bootstrap class, positioning the provider as a candidate for backing named persistence units. The provider supplies the provider configuration file by creating a text file named jakarta.persistence.spi.PersistenceProvider and placing it in the META-INF/services directory of one of its JAR files. The contents of the file should be the name of the provider implementation class of the jakarta.persistence.spi.PersistenceProvider interface.

Example:

A persistence vendor called ACME persistence products ships a JAR called acme.jar that contains its persistence provider implementation. The JAR includes the provider configuration file.

acme.jar
    META-INF/services/jakarta.persistence.spi.PersistenceProvider
    com.acme.PersistenceProvider
    ...

The contents of the META-INF/services/jakarta.persistence.spi.PersistenceProvider file is nothing more than the name of the implementation class: com.acme.PersistenceProvider.

Persistence provider jars may be installed or made available in the same ways as other service providers, e.g. as extensions or added to the application classpath.

The Persistence bootstrap class must locate all of the persistence providers using the PersistenceProviderResolver mechanism described in Section 9.3 and call createEntityManagerFactory on them in turn until an appropriate backing provider returns an EntityManagerFactory instance. A provider may deem itself as appropriate for the persistence unit if any of the following are true:

  • Its implementation class has been specified in the provider element for that persistence unit in the persistence.xml file and has not been overridden by a different jakarta.persistence.provider property value included in the Map passed to the createEntityManagerFactory method.

  • The jakarta.persistence.provider property was included in the Map passed to createEntityManagerFactory and the value of the property is the provider’s implementation class.

  • No provider was specified for the persistence unit in either the persistence.xml or the property map.

If a provider does not qualify as the provider for the named persistence unit, it must return null when createEntityManagerFactory is invoked on it.

9.2.1. Schema Generation

In Java SE environments, the Persistence.generateSchema method may be used by the application to cause schema generation to occur as a separate phase from entity manager factory creation.

In this case, the Persistence bootstrap class must locate all of the persistence providers using the PersistenceProviderResolver mechanism described in Section 9.3 and call generateSchema on them in turn until an appropriate backing provider returns true. A provider may deem itself as appropriate for the persistence unit if any of the following are true:

  • Its implementation class has been specified in the provider element for that persistence unit in the persistence.xml file and has not been overridden by a different jakarta.persistence.provider property value included in the Map passed to the generateSchema method.

  • The jakarta.persistence.provider property was included in the Map passed to generateSchema and the value of the property is the provider’s implementation class.

  • No provider was specified for the persistence unit in either the persistence.xml or the property map.

If a provider does not qualify as the provider for the named persistence unit, it must return false when generateSchema is invoked on it.

9.3. Determining the Available Persistence Providers

The PersistenceProviderResolver and PersistenceProviderResolverHolder mechanism supports the dynamic discovery of persistence providers.[100]

  • The PersistenceProviderResolver instance is responsible for returning the list of providers available in the environment.

  • The PersistenceProviderResolverHolder class holds the PersistenceProviderResolver instance that is in use.

These interfaces may be found in Appendix E.

The implementation of PersistenceProviderResolverHolder must be threadsafe, but no guarantee is made against multiple threads setting the resolver.

The container is allowed to implement and set a specific PersistenceProviderResolver provided that it respects the PersistenceProviderResolver contract. The PersistenceProviderResolver instance to be used is set by the container using the PersistenceProviderResolverHolder.setPersistenceProviderResolver method.[101]

If no PersistenceProviderResolver is set, the PersistenceProviderResolverHolder must return a PersistenceProviderResolver that returns the providers whose persistence provider jars have been installed or made available as service providers or extensions. This default PersistenceProviderResolver instance does not guarantee the order in which persistence providers are returned.

A PersistenceProviderResolver must be threadsafe.

The PersistenceProviderResolver.getPersistenceProviders() method must be used to determine the list of available persistence providers.

The results of calling the PersistenceProviderResolverHolder.getPersistenceProviderResolver and the PersistenceProviderResolver.getPersistenceProviders methods must not be cached. In particular, the following methods must use the PersistenceProviderResolver instance returned by the PersistenceProviderResolverHolder.getPersistenceProviderResolver method to determine the list of available providers:

  • Persistence.createEntityManagerFactory(String)

  • Persistence.createEntityManagerFactory(String, Map)

  • PersistenceUtil.isLoaded(Object)

  • PersistenceUtil.isLoaded(Object, String)

These methods must not cache the list of providers and must not cache the PersistenceProviderResolver instance.

Note that the PersistenceProviderResolver.getPersistenceProviders() method can potentially be called many times. It is therefore recommended that the implementation of this method make use of caching.

Note that only a single PersistenceProviderResolver instance can be defined in a given classloader hierarchy at a given time.

9.4. Schema Generation

In cases where a preconfigured database (or a “legacy” database) is not used or is not available, the Jakarta Persistence schema generation facility may be used to generate the tables and other database artifacts required by the persistence application. Whether schema generation entails the creation of schemas proper in the database is determined by the environment and the configuration of the schema generation process, as described below.

Schema generation may happen either prior to application deployment or when the entity manager factory is created as part of the application deployment and initialization process.

  • In Jakarta EE environments, the container may call the PersistenceProvider generateSchema method separately from and/or prior to the creation of the entity manager factory for the persistence unit, or the container may pass additional information to the createContainerEntityManagerFactory call to cause schema generation to happen as part of the entity manager factory creation and application initialization process. The information passed to these methods controls whether the generation occurs directly in the target database, whether DDL scripts for schema generation are created, or both.

  • In Java SE environments, the application may call the Persistence generateSchema method separately from and/or prior to the creation of the entity manager factory or may pass information to the createEntityManagerFactory method to cause schema generation to occur as part of the entity manager factory creation.

The application may provide DDL scripts to be used for schema generation as described in Section 8.2.1.11. The application developer may package these scripts as part of the persistence unit or may specify strings corresponding to file URLs for the location of such scripts. In Jakarta EE environments, such scripts may be executed by the container, or the container may direct the persistence provider to execute the scripts. In Java SE environments, the execution of the scripts is the responsibility of the persistence provider. In the absence of the specification of scripts, schema generation, if requested, will be determined by the object/relational metadata of the persistence unit.

The following standard properties are defined for configuring the schema generation process. In Jakarta EE environments these properties are passed by the container in the Map argument to either the PersistenceProvider generateSchema method or the createContainerEntityManagerFactory method. In Java SE environments, they are passed in the Map argument to either the Persistence generateSchema method or createEntityManagerFactory method.

In Jakarta EE environments, any strings corresponding to file URLs for script sources or targets must specify absolute paths (not relative). In Jakarta EE environments, all source and target file locations must be accessible to the application server deploying the persistence unit

jakarta.persistence.schema-generation.database.action

The jakarta.persistence.schema-generation.database.action property specifies the action to be taken by the persistence provider with regard to the database artifacts. The values for this property are "none", "create", "drop-and-create", "drop", "validate". If the jakarta.persistence.schema-generation.database.action property is not specified, no schema generation actions must be taken on the database.

jakarta.persistence.schema-generation.scripts.action

The jakarta.persistence.schema-generation.scripts.action property specifies which scripts are to be generated by the persistence provider. The values for this property are "none", "create", "drop-and-create" , "drop". A script will only be generated if the script target is specified. If this property is not specified, no scripts will be generated.

jakarta.persistence.schema-generation.create-source

The jakarta.persistence.schema-generation.create-source property specifies whether the creation of database artifacts is to occur on the basis of the object/relational mapping metadata, DDL script, or a combination of the two. The values for this property are "metadata", "script", "metadata-then-script", "script-then-metadata". If this property is not specified, and a script is specified by the jakarta.persistence.schema-generation.create-script-source property, the script (only) will be used for schema generation; otherwise if this property is not specified, schema generation will occur on the basis of the object/relational mapping metadata (only). The "metadata-then-script" and "script-then-metadata" values specify that a combination of metadata and script is to be used and the order in which this use is to occur. If either of these values is specified and the resulting database actions are not disjoint, the results are undefined and schema generation may fail.

jakarta.persistence.schema-generation.drop-source

The jakarta.persistence.schema-generation.drop-source property specifies whether the dropping of database artifacts is to occur on the basis of the object/relational mapping metadata, DDL script, or a combination of the two. The values for this property are "metadata", "script", "metadata-then-script", "script-then-metadata". If this property is not specified, and a script is specified by the jakarta.persistence.schema-generation.drop-script-source property, the script (only) will be used for the dropping of database artifacts; otherwise if this property is not specified, the dropping of database artifacts will occur on the basis of the object/relational mapping metadata (only). The "metadata-then-script" and "script-then-metadata" values specify that a combination of metadata and script is to be used and the order in which this use is to occur. If either of these values is specified and the resulting database actions are not disjoint, the results are undefined and the dropping of database artifacts may fail.

jakarta.persistence.schema-generation.create-database-schemas

In Jakarta EE environments, it is anticipated that the Jakarta EE platform provider may wish to control the creation of database schemas rather than delegate this task to the persistence provider. The jakarta.persistence.schema-generation.create-database-schemas property specifies whether the persistence provider is to create the database schema(s) in addition to creating database objects such as tables, sequences, constraints, etc. The value of this boolean property should be set to true if the persistence provider is to create schemas in the database or to generate DDL that contains “CREATE SCHEMA” commands. If this property is not supplied, the provider should not attempt to create database schemas. This property may also be specified in Java SE environments. jakarta.persistence.schema-generation.scripts.create-target,

jakarta.persistence.schema-generation.scripts.drop-target

If scripts are to be generated, the target locations for the writing of these scripts must be specified.
The jakarta.persistence.schema-generation.scripts.create-target property specifies a java.io.Writer configured for use by the persistence provider for output of the DDL script or a string specifying the file URL for the DDL script. This property should only be specified if scripts are to be generated.
The jakarta.persistence.schema-generation.scripts.drop-target property specifies a java.io.Writer configured for use by the persistence provider for output of the DDL script or a string specifying the file URL for the DDL script. This property should only be specified if scripts are to be generated.

jakarta.persistence.database-product-name,
jakarta.persistence.database-major-version,
jakarta.persistence.database-minor-version

If scripts are to be generated by the persistence provider and a connection to the target database is not supplied, the jakarta.persistence.database-product-name property must be specified. The value of this property should be the value returned for the target database by the JDBC DatabaseMetaData method getDatabaseProductName. If sufficient database version information is not included in the result of this method, the jakarta.persistence.database-major-version and jakarta.persistence.database-minor-version properties should be specified as needed. These should contain the values returned by the JDBC getDatabaseMajorVersion and getDatabaseMinorVersion methods respectively. jakarta.persistence.schema-generation.create-script-source,

jakarta.persistence.schema-generation.drop-script-source

The jakarta.persistence.schema-generation.create-script-source and jakarta.persistence.schema-generation.drop-script-source properties are used for script execution. In Jakarta EE container environments, it is generally expected that the container will be responsible for executing DDL scripts, although the container is permitted to delegate this task to the persistence provider. If DDL scripts are to be used in Java SE environments or if the Jakarta EE container delegates the execution of scripts to the persistence provider, these properties must be specified.
The jakarta.persistence.schema-generation.create-script-source property specifies a java.io.Reader configured for reading of the DDL script or a string designating a file URL for the DDL script.
The jakarta.persistence.schema-generation.drop-script-source property specifies a java.io.Reader configured for reading of the DDL script or a string designating a file URL for the DDL script.

jakarta.persistence.schema-generation.connection

The jakarta.persistence.schema-generation.connection property specifies the JDBC connection to be used for schema generation. This is intended for use in Jakarta EE environments, where the platform provider may want to control the database privileges that are available to the persistence provider. This connection is provided by the container, and should be closed by the container when the schema generation request or entity manager factory creation completes. The connection provided must have credentials sufficient for the persistence provider to carry out the requested actions. If this property is not specified, the persistence provider should use the DataSource that has otherwise been provided.

9.4.1. Data Loading

Data loading, by means of the use of SQL scripts, may occur as part of the schema generation process after the creation of the database artifacts or independently of schema generation. The specification of the jakarta.persistence.sql-load-script-source controls whether data loading will occur.

jakarta.persistence.sql-load-script-source

In Jakarta EE container environments, it is generally expected that the container will be responsible for executing data load scripts, although the container is permitted to delegate this task to the persistence provider. If a load script is to be used in Java SE environments or if the Jakarta EE container delegates the execution of the load script to the persistence provider, this property must be specified. + The jakarta.persistence.sql-load-script-source property specifies a java.io.Reader configured for reading of the SQL load script for database initialization or a string designating a file URL for the script.

9.5. Responsibilities of the Persistence Provider

The persistence provider must implement the PersistenceProvider SPI.

In Jakarta EE environments, the persistence provider must process the metadata that is passed to it at the time createContainerEntityManagerFactory method is called and create an instance of EntityManagerFactory using the PersistenceUnitInfo metadata for the factory. The factory is then returned to the container.

In Java SE environments, the persistence provider must validate the persistence.xml file against the persistence schema that corresponds to the version specified by the persistence.xml file and report any validation errors.

The persistence provider processes the metadata annotations on the managed classes of the persistence unit.

When the entity manager factory for a persistence unit is created, it is the responsibility of the persistence provider to initialize the state of the metamodel classes of the persistence unit.

When the persistence provider obtains an object/relational mapping file, it processes the definitions that it contains. The persistence provider must validate any object/relational mapping files against the object/relational mapping schema version specified by the object/relational mapping file and report any validation errors. The object relational mapping file must specify the object/relational mapping schema that it is written against by indicating the version element.

In Java SE environments, the application can pass the ValidatorFactory instance via the map that is passed as an argument to the Persistence.createEntityManagerFactory call. The map key used must be the standard property name jakarta.persistence.validation.factory. If no ValidatorFactory instance is provided by the application, and if a Bean Validation provider is present in the classpath, the persistence provider must instantiate the ValidatorFactory using the default bootstrapping approach as defined by the Bean Validation specification [5], namely Validation.buildDefaultValidatorFactory().

9.5.1. jakarta.persistence.spi.PersistenceProvider

The PersistenceProvider interface found in Section E.3 must be implemented by the persistence provider.

The PersistenceProvider implementation class must have a public constructor with no parameters.

An instance of PersistenceProvider is responsible for creating provider-specific implementations of EntityManagerFactory. It is invoked by the container in Jakarta EE environments and by the jakarta.persistence.Persistence class in Java SE environments. The jakarta.persistence.spi.PersistenceProvider implementation is not intended to be used by the application.

The properties passed to the createEntityManagerFactory() method in Java SE environments are described further in Section 9.7 below.

9.5.2. jakarta.persistence.spi.ProviderUtil

The ProviderUtil interface found in Section E.7 is called by the PersistenceUtil implementation to determine the load status of an entity or entity attribute. It is not intended to be invoked by the application.

9.6. jakarta.persistence.spi.PersistenceUnitInfo Interface

The PersistenceUnitInfo interface may be found in Section E.6.

The enum jakarta.persistence.spi.PersistenceUnitTransactionType defines whether the entity managers created by the factory will be JTA or resource-local entity managers. This enum is deprecated.

/**
 * Specifies whether entity managers created by the
 * {@link jakarta.persistence.EntityManagerFactory}
 * are JTA or resource-local entity managers.
 *
 * @since 1.0
 *
 * @deprecated replaced by
 * {@link jakarta.persistence.PersistenceUnitTransactionType}
 */
@Deprecated(since = "3.2", forRemoval = true)
public enum PersistenceUnitTransactionType {

    /** JTA entity managers are created. */
    JTA,
        
    /** Resource-local entity managers are created. */
    RESOURCE_LOCAL
}

The enum jakarta.persistence.SharedCacheMode defines the use of caching. The persistence.xml shared-cache-mode element has no default value. The getSharedCacheMode method must return UNSPECIFIED if the shared-cache-mode element has not been specified for the persistence unit.

import jakarta.persistence.spi.PersistenceUnitInfo;

/**
 * Specifies how the provider must use a second-level cache for the
 * persistence unit. Corresponds to the value of the {@code persistence.xml}
 * {@code shared-cache-mode} element, and returned as the result of
 * {@link PersistenceUnitInfo#getSharedCacheMode()}.
 * 
 * @since 2.0
 */
public enum SharedCacheMode {

    /**
     * All entities and entity-related state and data are cached.
     */
    ALL, 

    /**
     * Caching is disabled for the persistence unit.
     */
    NONE, 

    /**
     * Caching is enabled for all entities for which
     * {@link Cacheable Cacheable(true)} is specified. All other
     * entities are not cached.
     */
    ENABLE_SELECTIVE, 

    /**
     * Caching is enabled for all entities except those for which
     * {@link Cacheable Cacheable(false)} is specified. Entities
     * for which {@code Cacheable(false)} is specified are not cached.
     */
    DISABLE_SELECTIVE, 

    /**
     * Caching behavior is undefined: provider-specific defaults may apply.
     */
    UNSPECIFIED
}

The enum jakarta.persistence.ValidationMode defines the validation mode.

/**
 * The validation mode to be used by the provider for the persistence
 * unit.
 * 
 * @since 2.0
 */
public enum ValidationMode {
   
    /**
     * If a Bean Validation provider is present in the environment,
     * the persistence provider must perform the automatic validation
     * of entities. If no Bean Validation provider is present in the
     * environment, no lifecycle event validation takes place.
     * This is the default behavior.
     */
    AUTO,

    /**
     * The persistence provider must perform the lifecycle event
     * validation. It is an error if there is no Bean Validation
     * provider present in the environment.
     */
    CALLBACK,

    /**
     * The persistence provider must not perform lifecycle event
     * validation.
     */
    NONE
}

9.6.1. jakarta.persistence.spi.ClassTransformer Interface

The ClassTransformer interface found in Section E.1 may be implemented by a persistence provider to transform entities and managed classes at class load time or at class redefinition time. A persistence provider is not required to implement this interface.

9.7. jakarta.persistence.Persistence Class

The Persistence class may be found in Section B.17.

The Persistence class is used to obtain an EntityManagerFactory instance in Java SE environments. It may also be used for schema generation—i.e., to create database schemas and/or tables and/or to create DDL scripts.

The Persistence class is also available in a Jakarta EE container environment; however, support for the Java SE bootstrapping APIs is not required in container environments.

The Persistence class is used to obtain a PersistenceUtil instance in both Jakarta EE and Java SE environments.

The properties argument passed to the createEntityManagerFactory method is used to specify both standard and vendor-specific properties and hints intended for use in creating the entity manager factory and controlling its behavior.

The following properties correspond to the elements and attributes in the persistence.xml file. When any of these properties are specified in the Map parameter passed to the createEntityManagerFactory method, their values override the values of the corresponding elements and attributes in the persistence.xml file for the named persistence unit. They also override any defaults that the persistence provider might have applied.

Property Type Corresponding element in persistence.xml Notes

jakarta.persistence.provider

String

provider

See Section 8.2.1.4.

jakarta.persistence.qualifiers

String[]

qualifier

See Section 8.2.1.5.

jakarta.persistence.scope

String

scope

See Section 8.2.1.5.

jakarta.persistence.transactionType

String

transaction-type

See Section 8.2.1.2.

jakarta.persistence.jtaDataSource

String

jta-data-source

See Section 8.2.1.7.

jakarta.persistence.nonJtaDataSource

String

non-jta-data-source

See Section 8.2.1.7.

jakarta.persistence.sharedCache.mode

String

shared-cache-mode

See Section 8.2.1.9.

jakarta.persistence.validation.mode

String

validation-mode

Legal values are " auto ", " callback ", or " none ". See Section 8.2.1.10 and Section 3.7.1.1.

The following properties correspond to the properties in the persistence.xml ile. When any of these properties are specified in the Map parameter passed to the createEntityManagerFactory method, their values override the values of the corresponding properties in the persistence.xml file for the named persistence unit. They also override any defaults that the persistence provider might have applied.

Property Type Corresponding property in persistence.xml Notes

jakarta.persistence.lock.timeout

Integer or String

jakarta.persistence.lock.timeout

Hint only. Value in milliseconds for pessimistic lock timeout. See Section 3.5.4.3.

jakarta.persistence.query.timeout

Integer or String

jakarta.persistence.query.timeout

Hint only. Value in milliseconds for query timeout. See Section 3.11.4.

jakarta.persistence.validation.group.pre-persist

String

jakarta.persistence.validation.group.pre-persist

See Section 8.2.1.11 and Section 3.7.1.2.

jakarta.persistence.validation.group.pre-update

String

jakarta.persistence.validation.group.pre-update

See Section 8.2.1.11 and Section 3.7.1.2.

jakarta.persistence.validation.group.pre-remove

String

jakarta.persistence.validation.group.pre-remove

See Section 8.2.1.11 and Section 3.7.1.2.

jakarta.persistence.schema-generation.create-script-source

String

jakarta.persistence.schema-generation.create-script-source

See Section 8.2.1.11.

jakarta.persistence.schema-generation.drop-script-source

String

jakarta.persistence.schema-generation.drop-script-source

See Section 8.2.1.11.

jakarta.persistence.sql-load-script-source

String

jakarta.persistence.sql-load-script-source

See Section 8.2.1.11.

jakarta.persistence.schema-generation.database.action

String

jakarta.persistence.schema-generation.database.action

See Section 8.2.1.11.

jakarta.persistence.schema-generation.scripts.action

String

jakarta.persistence.schema-generation.scripts.action

See Section 8.2.1.11.

jakarta.persistence.schema-generation.create-source

String

jakarta.persistence.schema-generation.create-source

See Section 8.2.1.11.

jakarta.persistence.schema-generation.drop-source

String

jakarta.persistence.schema-generation.drop-source

See Section 8.2.1.11.

jakarta.persistence.schema-generation.scripts.create-target

String

jakarta.persistence.schema-generation.scripts.create-target

See Section 8.2.1.11.

jakarta.persistence.schema-generation.scripts.drop-target

String

jakarta.persistence.schema-generation.scripts.drop-target

See Section 8.2.1.11.

The following additional standard properties are defined by this specification for the configuration of the entity manager factory:

Property Value

jakarta.persistence.jdbc.driver

Fully qualified name of the driver class.

jakarta.persistence.jdbc.url

Driver-specific JDBC URL as a string.

jakarta.persistence.jdbc.user

Username for database connection.

jakarta.persistence.jdbc.password

Password for database connection authentication.

jakarta.persistence.dataSource

Instance of javax.sql.DataSource to be used for the specified persistence unit.

jakarta.persistence.validation.factory

Instance of jakarta.validation.ValidatorFactory.

Any number of vendor-specific properties may also be included in the map. If a persistence provider does not recognize a property (other than a property defined by this specification), the provider must ignore it.

Vendors should use vendor namespaces for properties (e.g., com.acme.persistence.logging). Entries that make use of the namespace jakarta.persistence and its subnamespaces must not be used for vendor-specific information. The namespace jakarta.persistence is reserved for use by this specification.

9.8. jakarta.persistence.PersistenceConfiguration Class

The PersistenceConfiguration class found in Section B.18 is used to programmatically define and configure a persistence unit and create an EntityManagerFactory instance directly. Thus, PersistenceConfiguration is an alternative to XML-based configuration using persistence.xml, and so the configuration options available via this API reflect the similarly-named elements of persistence.xml. See Section 8.2.1.

A programmatically-configured persistence unit is considered a Java SE persistence unit, even when this API is used within the Jakarta EE environment.[102]

A persistence provider may define a subclass of PersistenceConfiguration with vendor-specific configuration options. A provider must support configuration via any instance of PersistenceConfiguration or of any subclass of PersistenceConfiguration. If a subclass defines configuration options the provider does not recognize, it should ignore those options.

9.9. PersistenceUtil Interface

The PersistenceUtil interface found in Section B.19 is used to determine the load state of entity instances. The semantics of the methods of this interface are defined in Section 9.9.1 below.

9.9.1. Contracts for Determining the Load State of an Entity or Entity Attribute

The implementation of the PersistenceUtil.isLoaded(Object) method must determine the list of persistence providers available in the runtime environment[103] and call the ProviderUtil.isLoaded(Object) method on each of them until either:

  • one provider returns LoadState.LOADED. In this case PersistenceUtil.isLoaded returns true.

  • one provider returns LoadState.NOT_LOADED. In this case PersistenceUtil.isLoaded returns false.

  • all providers return LoadState.UNKNOWN. In this case PersistenceUtil.isLoaded returns true.

If the PersistenceUtil implementation determines that only a single provider is available in the environment, it is permitted to use provider-specific methods to determine the result of isLoaded(Object) as long as the semantics defined in Section 3.3.9 are observed.

The implementation of the PersistenceUtil.isLoaded(Object,String) method must determine the list of persistence providers available in the environment and call the ProviderUtil.isLoadedWithoutReference method on each of them until either:

  • one provider returns LoadState.LOADED. In this case PersistenceUtil.isLoaded returns true.

  • one provider returns LoadState.NOT_LOADED. In this case PersistenceUtil.isLoaded returns false.

  • all providers return LoadState.UNKNOWN. In this case, the PersistenceUtil.isLoaded method then calls ProviderUtil.isLoadedWithReference on each of the providers until:

    • one provider returns LoadState.LOADED. In this case PersistenceUtil.isLoaded return true.

    • one provider returns LoadState.NOT_LOADED. In this case, PersistenceUtil.isLoaded returns false.

    • all providers return LoadState.UNKNOWN. In this case, PersistenceUtil.isLoaded returns true.

If the PersistenceUtil implementation determines that only a single provider is available in the environment, it is permitted to use provider specific methods to determine the result of isLoaded(Object, String) as long as the semantics defined in Section 3.3.9 are observed.

The rationale for splitting the determination of load state between the methods isLoadedWithoutReference and isLoadedWithReference is the following.
  • It is assumed that the provider that loaded the entity is present in the environment.

  • Providers that use bytecode enhancement don’t need to access an attribute reference to determine its load state, and can determine if the entity has been provided by them.

  • By first querying all providers using bytecode enhancement, it is insured that no attribute will be loaded by side effect.

  • Proxy-based providers do need to access an attribute reference to determine load state, but will not trigger attribute loading as a side effect.

  • If no provider recognizes an entity as provided by it, it is assumed to be an object that is not instrumented and is considered loaded.

10. Metadata Annotations

This chapter and chapter Chapter 11 define the metadata annotations introduced by this specification.

The XML schema defined in chapter Chapter 12 provides an alternative to the use of metadata annotations.

These annotations and types are in the package jakarta.persistence.

10.1. Entity

The Entity annotation specifies that the class is an entity. This annotation is applied to the entity class.

The name annotation element specifies the entity name. If the name element is not specified, the entity name defaults to the unqualified name of the entity class. This name is used to refer to the entity in queries.

@Documented
@Target(TYPE)
@Retention(RUNTIME)
public @interface Entity {
    String name() default "";
}

10.2. Callback Annotations

The EntityListeners annotation specifies the callback listener classes to be used for an entity or mapped superclass. The EntityListeners annotation may be applied to an entity class or mapped superclass.

@Target({TYPE})
@Retention(RUNTIME)
public @interface EntityListeners {
    Class[] value();
}

The ExcludeSuperclassListeners annotation specifies that the invocation of superclass listeners is to be excluded for the entity class (or mapped superclass) and its subclasses.

@Target({TYPE})
@Retention(RUNTIME)
public @interface ExcludeSuperclassListeners {
}

The ExcludeDefaultListeners annotation specifies that the invocation of default listeners is to be excluded for the entity class (or mapped superclass) and its subclasses.

@Target({TYPE})
@Retention(RUNTIME)
public @interface ExcludeDefaultListeners {
}

The following annotations are used to specify callback methods for the corresponding lifecycle events. These annotations may be applied to methods of an entity class, of a mapped superclass, or of an entity listener class.

@Target({METHOD})
@Retention(RUNTIME)
public @interface PrePersist {}

@Target({METHOD})
@Retention(RUNTIME)
public @interface PostPersist {}

@Target({METHOD})
@Retention(RUNTIME)
public @interface PreRemove {}

@Target({METHOD})
@Retention(RUNTIME)
public @interface PostRemove {}

@Target({METHOD})
@Retention(RUNTIME)
public @interface PreUpdate {}

@Target({METHOD})
@Retention(RUNTIME)
public @interface PostUpdate {}

@Target({METHOD})
@Retention(RUNTIME)
public @interface PostLoad {}

10.3. EntityGraph Annotations

10.3.1. NamedEntityGraph and NamedEntityGraphs Annotations

The NamedEntityGraph annotation defines a named entity graph. The annotation must be applied to the root entity of the graph, and specifies the limits of the graph of associated attributes and entities fetched when an operation which retrieves an instance or instances of the root entity is executed.

The name element assigns a name to the entity graph, and is used to identify the entity graph in calls to EntityManager.getEntityGraph(). If no name is explicitly specified, the name defaults to the entity name of the annotated root entity. Entity graph names must be unique within the persistence unit.

The attributeNodes element lists attributes of the annotated entity class that are to be included in the entity graph.

The includeAllAttributes element specifies that all attributes of the annotated entity class are to be included in the entity graph. An attributeNode element may still be used in conjunction with this element to specify a subgraph for the attribute.

The subgraphs element specifies a list of subgraphs, further specifying attributes that are managed types. These subgraphs are referenced by name from NamedAttributeNode definitions.

The subclassSubgraphs element specifies a list of subgraphs that add additional attributes for subclasses of the root entity to which the annotation is applied.

The NamedEntityGraphs annotation can be used to specify multiple named entity graphs for the entity to which it is applied.

@Target({TYPE})
@Retention(RUNTIME)
@Repeatable(NamedEntityGraphs.class)
public @interface NamedEntityGraph {
    String name() default "";
    NamedAttributeNode[] attributeNodes() default {};
    boolean includeAllAttributes() default false;
    NamedSubgraph[] subgraphs() default {};
    NamedSubgraph[] subclassSubgraphs() default {};
}

@Target({TYPE})
@Retention(RUNTIME)
public @interface NamedEntityGraphs {
    NamedEntityGraph[] value();
}

10.3.2. NamedAttributeNode Annotation

The NamedAttributeNode annotation is used to specify an attribute node of within an entity graph or subgraph.

The value element specifies the name of the corresponding attribute.

The subgraph element is used to refer to a NamedSubgraph specification that further characterizes an attribute node corresponding to a managed type (entity or embeddable). The value of the subgraph element must correspond to the name used for the subgraph in the NamedSubgraph element. If the referenced attribute is an entity which has entity subclasses, there may be more than one NamedSubgraph element with this name, and the subgraph element is considered to refer to all of these.

The keySubgraph element is used to refer to a NamedSubgraph specification that further characterizes an attribute node corresponding to the key of a Map-valued attribute. The value of the the keySubgraph element must correspond to the name used for the subgraph in the NamedSubgraph element. If the referenced attribute is an entity which has entity subclasses, there may be more than one NamedSubgraph element with this name, and the keySubgraph element is considered to refer to all of these.

@Target({})
@Retention(RUNTIME)
public @interface NamedAttributeNode {
    String value();
    String subgraph() default "";
    String keySubgraph() default "";
}

10.3.3. NamedSubgraph Annotation

The NamedSubgraph annotation is used to further define an attribute node. It is referenced by its name from the subgraph or keySubgraph element of a NamedAttributeNode element.

The name element is the name used to reference the subgraph from a NamedAttributeNode definition. In the case of entity inheritance, multiple subgraph elements have the same name.

The type element must be specified when the subgraph corresponds to a subclass of the entity type corresponding to the referencing attribute node.

The attributeNodes element lists attributes of the class that must be included. If the subgraph corresponds to a subclass of the class referenced by the corresponding attribute node, only subclass-specific attributes are listed.

@Target({})
@Retention(RUNTIME)
public @interface NamedSubgraph {
    String name();
    Class type() default void.class;
    NamedAttributeNode[] attributeNodes();
}

10.4. Annotations for Queries

The following annotations are used to declare named queries.

10.4.1. NamedQuery Annotation

The NamedQuery annotation declared a named query written in the Jakarta Persistence query language.

The name element assigns a name to the query, which is used to identify the query in calls to EntityManager.createNamedQuery().

The query element must specify a query string itself, written in the Jakarta Persistence query language.

The resultClass element specifies the Java class of each query result. The query result class may be overridden by explicitly passing a Class object to EntityManager.createNamedQuery(String, Class). If the resultClass element of a NamedQuery annotation is not specified, the persistence implementation is entitled to default the result class to Object or Object[].

The lockMode element specifies a lock mode for the entity instances in results returned by the query. If a lock mode other than NONE is specified, the query may only be executed within a persistence context with an associated active transaction.

The hints elements may be used to specify query properties and hints. Properties defined by this specification must be observed by the provider; hints defined by this specification should be observed by the provider when possible. Vendor-specific hints that are not recognized by a provider must be ignored.

The NamedQuery and NamedQueries annotations can be applied to an entity or mapped superclass.

@Target({TYPE})
@Retention(RUNTIME)
@Repeatable(NamedQueries.class)
public @interface NamedQuery {
    String name();
    String query();
    Class<?> resultClass() default void.class;
    LockModeType lockMode() default NONE;
    QueryHint[] hints() default {};
}

@Target({})
@Retention(RUNTIME)
public @interface QueryHint {
    String name();
    String value();
}

@Target({TYPE})
@Retention(RUNTIME)
public @interface NamedQueries {
    NamedQuery[] value ();
}

10.4.2. NamedNativeQuery Annotation

The NamedNativeQuery annotation defines a named native SQL query.

The name element assigns a name to the query, which is used to identify the query in calls to EntityManager.createNamedQuery().

The query element must specify the query string itself, written in the native SQL dialect of the database.

The resultClass element specifies the class of each query result. If a result set mapping is specified, the specified result class must agree with the type inferred from the result set mapping. If a resultClass is not explicitly specified, then it is inferred from the result set mapping, if any, or defaults to Object or Object[]. The query result class may be overridden by explicitly passing a Class object to EntityManager.createNamedQuery(String, Class).

The resultSetMapping element specifies the name of a SqlResultSetMapping specification defined elsewhere in metadata. The named SqlResultSetMapping is used to interpret the result set of the native SQL query. Alternatively, the elements entities, classes, and columns may be used to specify a result set mapping. These elements may not be used in conjunction with resultSetMapping.

The hints element may be used to specify query properties and hints. Hints defined by this specification should be observed by the provider when possible. Vendor-specific hints which are not recognized by the provider must be ignored.

The NamedNativeQuery and NamedNativeQueries annotations can be applied to an entity or mapped superclass.

@Target({TYPE})
@Retention(RUNTIME)
@Repeatable(NamedNativeQueries.class)
public @interface NamedNativeQuery {
    String name();
    String query();
    QueryHint[] hints() default {};
    Class resultClass() default void.class;
    String resultSetMapping() default "";
    EntityResult[] entities() default {};
    ConstructorResult[] classes() default {};
    ColumnResult[] columns() default {};
}

@Target({TYPE})
@Retention(RUNTIME)
public @interface NamedNativeQueries {
    NamedNativeQuery[] value ();
}

10.4.3. NamedStoredProcedureQuery Annotation

The NamedStoredProcedureQuery annotation is used to specify a stored procedure, its parameters, and its result type.

The name element is the name that is passed as an argument to the createNamedStoredProcedureQuery method to create an executable StoredProcedureQuery object.

The procedureName element is the name of the stored procedure in the database.

The parameters of the stored procedure are specified by the parameters element. All parameters must be specified in the order in which they occur in the parameter list of the stored procedure.

The resultClasses element refers to the class (or classes) that are used to map the results. The resultSetMappings element names one or more result set mappings, as defined by the SqlResultSetMapping annotation.

If there are multiple result sets, it is assumed that they will be mapped using the same mechanism—e.g., either all via a set of result class mappings or all via a set of result set mappings. The order of the specification of these mappings must be the same as the order in which the result sets will be returned by the stored procedure invocation. If the stored procedure returns one or more result sets and no resultClasses or resultSetMappings element is specified, any result set will be returned as a list of type Object[] . The combining of different strategies for the mapping of stored procedure result sets is undefined.

The hints element may be used to specify query properties and hints. Properties defined by this specification must be observed by the provider. Vendor-specific hints that are not recognized by a provider must be ignored.

The NamedStoredProcedureQuery and NamedStoredProcedureQueries annotations can be applied to an entity or mapped superclass.

@Target(TYPE)
@Retention(RUNTIME)
@Repeatable(NamedStoredProcedureQueries.class)
public @interface NamedStoredProcedureQuery {
    String name();
    String procedureName();
    StoredProcedureParameter[] parameters() default {};
    Class[] resultClasses() default {};
    String[] resultSetMappings() default {};
    QueryHint[] hints() default {};
}

@Target(TYPE)
@Retention(RUNTIME)
public @interface NamedStoredProcedureQueries {
    NamedStoredProcedureQuery [] value;
}

All parameters of a named stored procedure query must be specified using the StoredProcedureParameter annotation. The name element refers to the name of the parameter as defined by the stored procedure in the database. If a parameter name is not specified, it is assumed that the stored procedure uses positional parameters. The mode element specifies whether the parameter is an IN, INOUT, OUT, or REF_CURSOR parameter. REF_CURSOR parameters are used by some databases to return result sets from stored procedures. The type element refers to the JDBC type for the parameter.

@Target({})
@Retention(RUNTIME)
public @interface StoredProcedureParameter {
    String name() default "";
    ParameterMode mode() default ParameterMode.IN;
    Class type();
}

public enum ParameterMode {
    IN,
    INOUT,
    OUT,
    REF_CURSOR
}

10.4.4. Annotations for SQL Result Set Mappings

The SqlResultSetMapping annotation is used to specify the mapping of the result set of a native SQL query or stored procedure.

@Target({TYPE})
@Retention(RUNTIME)
@Repeatable(SqlResultSetMappings.class)
public @interface SqlResultSetMapping {
    String name();
    EntityResult[] entities() default {};
    ConstructorResult[] classes() default {};
    ColumnResult[] columns() default {};
}

@Target({TYPE})
@Retention(RUNTIME)
public @interface SqlResultSetMappings {
    SqlResultSetMapping[] value();
}

The name element is the name given to the result set mapping, and is used to identify it when calling methods of the EntityManager which create instances of Query and StoredProcedureQuery. The entities, classes, and columns elements are used to specify the mapping of result set columns to entities, to constructors, and to scalar values, respectively.

@Target({})
@Retention(RUNTIME)
public @interface EntityResult {
    Class entityClass();
    LockModeType lockMode() default LockModeType.OPTIMISTIC;
    FieldResult[] fields() default {};
    String discriminatorColumn() default "";
}

The entityClass element specifies the class of the result.

The lockMode element specifies the LockModeType obtained when the native SQL query is executed.

The fields element is used to map the columns specified in the SELECT list of the query to the properties or fields of the entity class.

The discriminatorColumn element is used to specify the column name (or alias) of the column in the SELECT list that is used to determine the type of the entity instance.

@Target({})
@Retention(RUNTIME)
public @interface FieldResult {
    String name();
    String column();
}

The name element is the name of the persistent field or property of the class.

The column element specifies the name of the corresponding column in the SELECT list—i.e., column alias, if applicable.

@Target(value={})
@Retention(RUNTIME)
public @interface ConstructorResult {
    Class targetClass();
    ColumnResult[] columns();
}

The targetClass element specifies the class whose constructor is to be invoked.

The columns element specifies the mapping of columns in the SELECT list to the arguments of the intended constructor.

@Target({})
@Retention(RUNTIME)
public @interface ColumnResult {
    String name();
    Class type() default void.class;
}

The name element specifies the name of the column in the SELECT list.

The type element specifies the Java type to which the column type is to be mapped. If the type element is not specified, the default JDBC type mapping for the column will be used.

10.5. References to EntityManager and EntityManagerFactory

These annotations are used to express dependencies on entity managers and entity manager factories.

10.5.1. PersistenceContext Annotation

The PersistenceContext annotation is used to express a dependency on a container-managed entity manager and its associated persistence context.

The name element refers to the name by which the entity manager is to be accessed in the environment referencing context, and is not needed when dependency injection is used.

The optional unitName element refers to the name of the persistence unit. If the unitName element is specified, the persistence unit for the entity manager that is accessible in JNDI must have the same name.

The type element specifies whether a transaction-scoped or extended persistence context is to be used. If the type element is not specified, a transaction-scoped persistence context is used.

The synchronizationType element specifies whether the persistence context is always automatically synchronized with the current transaction or whether the persistence context must be explicitly joined to the current transaction by means of the joinTransaction method of EntityManager.

The optional properties element may be used to specify properties for the container or persistence provider. Properties defined by this specification must be observed by the provider. Vendor specific properties may be included in the set of properties, and are passed to the persistence provider by the container when the entity manager is created. Properties that are not recognized by a vendor must be ignored.

@Target({TYPE, METHOD, FIELD})
@Retention(RUNTIME)
@Repeatable(PersistenceContexts.class)
public @interface PersistenceContext {
    String name() default "";
    String unitName() default "";
    PersistenceContextType type() default TRANSACTION;
    SynchronizationType synchronization() default SYNCHRONIZED;
    PersistenceProperty[] properties() default {};
}

public enum PersistenceContextType {
    TRANSACTION,
    EXTENDED
}

public enum SynchronizationType {
    SYNCHRONIZED,
    UNSYNCHRONIZED
}

@Target({})
@Retention(RUNTIME)
public @interface PersistenceProperty {
    String name();
    String value();
}

The PersistenceContexts annotation declares one or more PersistenceContext annotations. It is used to express a dependency on multiple persistence contexts[104].

@Target({TYPE})
@Retention(RUNTIME)
public @interface PersistenceContexts {
    PersistenceContext[] value();
}

10.5.2. PersistenceUnit Annotation

The PersistenceUnit annotation is used to express a dependency on an entity manager factory and its associated persistence unit.

The name element refers to the name by which the entity manager factory is to be accessed in the environment referencing context, and is not needed when dependency injection is used.

The optional unitName element refers to the name of the persistence unit as defined in the persistence.xml file. If the unitName element is specified, the persistence unit for the entity manager factory that is accessible in JNDI must have the same name.

@Target({TYPE, METHOD, FIELD})
@Retention(RUNTIME)
@Repeatable(PersistenceUnits.class)
public @interface PersistenceUnit {
    String name() default "";
    String unitName() default "";
}

The PersistenceUnits annotation declares one or more PersistenceUnit annotations. It is used to express a dependency on multiple persistence units[105].

@Target(TYPE)
@Retention(RUNTIME)
public @interface PersistenceUnits {
    PersistenceUnit[] value();
}

10.6. Annotations for Attribute Converter Classes

The Converter annotation declares that the annotated class is a converter and specifies whether the converter is applied automatically. Every converter class must implement AttributeConverter and must be annotated with the Converter annotation or declared as a converter in the XML descriptor. The target type for a converter is determined by the actual type argument of the first type parameter of AttributeConverter.

@Target({TYPE})
@Retention(RUNTIME)
public @interface Converter {
    boolean autoApply() default false;
}

If the autoApply element is specified as true, the persistence provider must automatically apply the converter to every mapped attribute of the specified target type belonging to any entity in the persistence unit, except for attributes for which conversion is overridden by means of the Convert annotation (or XML equivalent). The Convert annotation is described in Section 11.1.10. The Convert annotation may be used to override or disable auto-apply conversion on a per-attribute basis.

In determining whether a converter applies to an attribute, the provider must treat primitive types and wrapper types as equivalent.

A converter never applies to id attributes, version attributes, relationship attributes, or to attributes explicitly annotated as Enumerated or Temporal (or designated as such via XML).

A converter never applies to any attribute annotated @Convert(disableConversion=true) or to an attribute for which the Convert annotation explicitly specifies a different converter.

If autoApply is false, the converter applies only to attributes of the target type for which conversion is explicitly enabled via the Convert annotation (or corresponding XML element).

If there is more than one converter defined for the same target type, the Convert annotation must be used to explicitly specify which converter applies.

11. Metadata for Object/Relational Mapping

The object/relational mapping metadata is part of the application domain model contract. It expresses requirements and expectations on the part of the application as to the mapping of the entities and relationships of the application domain to a database. Queries (and, in particular, SQL queries) written against the database schema that corresponds to the application domain model are dependent upon the mappings expressed by means of the object/relational mapping metadata. The implementation of this specification must assume this application dependency upon the object/relational mapping metadata and insure that the semantics and requirements expressed by that mapping are observed.

The use of object/relational mapping metadata to control schema generation is specified in Section 11.2.

11.1. Annotations for Object/Relational Mapping

These annotations and types are in the package jakarta.persistence.

XML metadata may be used as an alternative to these annotations, or to override or augment annotations, as described in Chapter 12.

11.1.1. Access Annotation

The Access annotation is used to specify an access type to be applied to an entity class, mapped superclass, or embeddable class, or to a specific attribute of such a class.

@Target({TYPE, METHOD, FIELD})
@Retention(RUNTIME)
public @interface Access {
    AccessType value();
}

Table 4 lists the annotation elements that may be specified for the Access annotation.

Table 4. Access Annotation Elements
Type Name Description Default

AccessType

value

(Required) The access type to be applied to the class or attribute.

11.1.2. AssociationOverride Annotation

The AssociationOverride annotation is used to override a mapping for an entity relationship.

The AssociationOverride annotation may be applied to an entity that extends a mapped superclass to override a relationship mapping defined by the mapped superclass. If the AssociationOverride annotation is not specified, the association is mapped the same as in the original mapping. When used to override a mapping defined by a mapped superclass, the AssociationOverride annotation is applied to the entity class.

The AssociationOverride annotation may be used to override a relationship mapping from an embeddable within an entity to another entity when the embeddable is on the owning side of the relationship. When used to override a relationship mapping defined by an embeddable class (including an embeddable class embedded within another embeddable class), the AssociationOverride annotation is applied to the field or property containing the embeddable.

When the AssociationOverride annotation is used to override a relationship mapping from an embeddable class, the name element specifies the referencing relationship field or property within the embeddable class. To override mappings at multiple levels of embedding, a dot (".") notation syntax must be used in the name element to indicate an attribute within an embedded attribute. The value of each identifier used with the dot notation is the name of the respective embedded field or property. When the AssociationOverride annotation is applied to override the mappings of an embeddable class used as a map value, " value. " must be used to prefix the name of the attribute within the embeddable class that is being overridden in order to specify it as part of the map value.[106