Interview Questions and Answers

JPA (Java Persistence API) is a Java EE and Java SE specification that describes a management system for saving java objects to relational database tables in a convenient form.

Java itself does not contain JPA implementations, however, there are many implementations of this specification from different companies (open and not). This is not the only way to save java objects in databases (ORM systems), but one of the most popular in the Java world.

• JPA is the standard, and standards are good!
• Using JPA does not tie you to Hibernate.
• JPA gives you most of the features of plain old Hibernate, except:
• No criteria queries in JPA 2.0. Criteria query is a neat feature of Hibernate that constructs queries using Java-based combinators instead of the alternate query language, getting the benefit of IntelliSense and Eclipse's refactoring tools.
• JPA doesn't have Hibernate's DeleteOrphan cascade type.
• Delete Orphan is a useful annotation that directs Hibernate to delete entities in a collection if the parent is deleted, preventing orphaning.
• JPA doesn't have an equivalent to Hibernate's ScrollableResults.

A class which should be persisted in a database it must be annotated with javax.persistence.Entity. Such a class is called Entity. 

Hibernate is one of the most popular open-source implementations of the latest specification (JPA 3.0). Even more likely the most popular, almost standard de facto.

That is, JPA only describes rules and APIs, and Hibernate implements these descriptions, however Hibernate (like many other JPA implementations) has additional features not described in JPA (and is not portable to other JPA implementations).

For solid differences, check JPA vs Hibernate.

JPA indicates that it can work both with properties of classes (property), designed in the style of JavaBeans, or with fields (field), that is, class variables (instance variables). Accordingly, the type of access will be either property access or field access.

There are four types of connections

1. One-To-One: one-to-one connection, that is, one Entity object can be associated with no more than one object of another Entity
2. One-To-Many: one-to-many connection, one Entity object can be associated with a whole collection of Entity
3. Many-To-One: A relationship where one entity (column or set of columns) is/are referenced with another entity (column or set of columns) that contains unique values. In relational databases, these relations are applicable by using foreign key/primary key between tables.
4. Many-To-Many: A relationship is a connection between two types of entities. In the case of a many-to-many relationship, both sides can relate to multiple instances of the other side. Note that it's possible for entity types to be in a relationship with themselves.

Bi-directional: A mapping is the most common way to model this relationship with JPA and Hibernate. It uses an attribute on the Order and the OrderItem entity. This allows you to navigate the association in both directions in your domain model and your JPQL queries.

Uni-directional: A mapping is an association between one persistence object and another one related persistence object. If one persistence object uses another and in back if other is not using the first persistence object then it becomes unidirectional.

• If the entity class uses persistent fields, the Persistence runtime accesses entity-class instance variables directly.
• All fields not annotated javax.persistence.Transient or not marked as Java transient will be persisted to the data store.
• The object/relational mapping annotations must be applied to the instance variables.

In general, the JPA specification says only about mapping java objects into relational database tables, but there are a number of implementations of this standard for NoSQL databases: Kundera, DataNucleus, ObjectDB, and a number of others. Naturally, not all specification-specific features for relational databases are transferred to NoSQL databases completely.

1) Entity class must be annotated with Entity or described in the XML configuration file JPA,

2) Entity class must contain a public or protected constructor with no arguments (it can also have constructors with arguments),

3) Entity class must be a top-level class (top-level class),

4) Entity class cannot be an enum or interface,

5) Entity class cannot be the final class,

6) Entity class cannot contain final fields or methods if they participate in the mapping (persistent final methods or persistent final instance variables),

7) If an Entity class object is passed by value as a separate object (detached object), for example through a remote interface (through a remote interface), it must also implement a Serializable interface,

8) The Entity class fields should be directly accessible only to the methods of the Entity class and should not be directly accessible to other classes using this entity. Such classes should refer only to methods (getter/setter methods or other business logic methods in the Entity class),

9) The Entity class must contain a primary key, that is, an attribute or group of attributes that uniquely defines the record of this Entity class in the database.

• If the entity uses persistent properties, the entity must follow the method conventions of JavaBeans components.
• JavaBeans-style properties use getter and setter methods that are typically named after the entity class's instance variable names.
• For every persistent property of type Type of the entity, there is a getter method getProperty and a setter method setProperty.
• If the property is a Boolean, you may use isProperty instead of getProperty. For example, if a Customer entity uses persistent properties and has a private instance variable called firstName, the class defines a getFirstName and setFirstName method for retrieving and setting the state of the firstName instance variable.
  
  The method signature for single-valued persistent properties are as follows:
  
  Type getProperty()
  void setProperty(Type type)
  
  The object/relational mapping annotations for persistent properties must be applied to the getter methods. Mapping annotations cannot be applied to fields or properties annotated @Transient or marked transient.

Key states that an entity might be in:

1. New / Transient: An object is instantiated but not yet associated with an Entity Manager and has no representation in the database.
2. Managed / Persisted.
3. Detached: Detached entity objects are objects in a special state in which they are not managed by any EntityManager but still represent objects in the database. Detached objects are often returned from a persistence tier to the web layer where they can be displayed to the end user in some form. Changes can be made to a detached object, but these changes won't be persisted in the database until the entity is reassociated with a persistence context (the entity is merged back to an EntityManager to become managed again).
4. Removed.
   
   - The merge method's major task is to transfer the state from an unmanaged entity (passed as the argument) to its managed counterpart within the persistence context.
   - Merge deals with both new and detached entities. Merge causes either INSERT or UPDATE operation according to the sub-scenario (on the one hand it is more robust, on the other hand, this robustness needn't be required.)
   - Persist always causes INSERT SQL operation is executed (i.e. an exception may be thrown if the entity has already been inserted and thus the primary key violation happens.)

@Override
@Transactional
public void create(Category entity) throws MeetingAppDAOException {
  try {
    logger.info("Enter - create()");
    super.create(entity);
    logger.info("Exit - create()");
  } catch (PersistenceException exception) {
    logger.error("create()::REASON OF EXCEPTION=" + exception.getMessage(), e);
  }
}

JPA indicates that it can work both with properties of classes (property), designed in the style of JavaBeans, or with fields (field), that is, class variables (instance variables). Both types of elements of the Entity class are called attributes of the Entity class.

• Entity manager javax.persistence.EntityManager provides the operations from and to the database, e.g. find objects, persists them, remove objects from the database, etc.
• Entities which are managed by an EntityManager will automatically propagate these changes to the database (if this happens within a commit statement). These objects are known as persistent object. 
• If the Entity Manager is closed (via close()) then the managed entities are in a detached state. These are known as the detached objects. If you want synchronize them again with the database, the a Entity Manager provides the merge() method. Once merged, the object(s) becomes perstent objects again.
• The EntityManager is the API of the persistence context, and an EntityManager can be injected directly in to a DAO without requiring a JPA Template. The Spring Container is capable of acting as a JPA container and of injecting the EntityManager by honoring the @PersistenceContext (both as field-level and a method-level annotation).

• Entities may use persistent fields, persistent properties, or a combination of both.
• If the mapping annotations are applied to the entity's instance variables, the entity uses persistent fields.
• If the mapping annotations are applied to the entity's getter methods for JavaBeans-style properties, the entity uses persistent properties.

Valid attribute types for Entity classes are:

1. primitive types and their Java wrappers,
2. strings,
3. any Java serializable types,
4. enums;
5. entity types;
6. embeddable classes
7. collection types

JPQL (Java Persistence Query Language) offers an object-oriented syntax for expressing queries that are very similar to SQL. The language is interpreted at runtime, which means you cannot use the compiler to verify the correctness and integrity of a query. To address this limitation, Hibernate includes a Criteria API, which allows queries to be expressed programmatically.

JPA (Java Persistence API) and Java Data Objects (JDO) are two specifications for storing java objects in databases.

If JPA is concentrated only on relational databases, then JDO is a more general specification that describes the ORM for any possible bases and repositories.

In principle, JPA can be viewed as part of the JDO specification specialized in relational databases, even though the API of these two specifications does not completely match.

The “developers” of specifications also differ – if JPA is developed as JSR, then JDO was first developed as JSR, and now it is developed as an Apache JDO project.

1. Such classes must satisfy the same rules as the Entity classes, except that they do not have to contain a primary key and be marked with the Entity annotation.
2. The Embeddable class must be marked with the Embeddable annotation or described in the XML configuration file JPA.

A mapped Superclass is a class from which Entity is inherited, it may contain JPA annotations, however, such a class is not Entity, it does not have to fulfill all the requirements set for Entity (for example, it may not contain a primary key).

Such a class cannot be used in EntityManager or Query operations. Such a class should be marked with the MappedSuperclass annotation or, respectively, described in the XML file.

• For the new status, the object will get saved to the database after a transaction is committed and changes to the status managed.
• If the status is managed, it ignores the operation. But the status of the dependent Entity can be changed to 'managed' if the cascading annotations are there.
• For the removed status, it changes to managed thereafter.
• For the detached status, it throws the exception at the transaction's commit stage or right away.

• For the new status, a new managed entity is created, and the past data will be copied into it.
• For the managed status, it ignores the operation, but it works on the Entity dependent on cascading when the status is not managed.
• For the removed status, it throws the exception at the transaction's commit stage or right away.
• For the detached status, it either creates a new managed with the data copied or copies the data to the existing managed Entity

• For the new status, it ignores the operation, but the status changes to removed on the Entity dependent on cascading. Here the status shouldn't be managed.
• For the managed status, the status changes to removed thereafter, and the removed database records the object during the commit stage.
• For the removed status, it ignores the operation.
• For the detached status, it throws the exception at the transaction's commit stage or right away.

• For the new or detached status, it ignores the operation.
• For the managed or removed status, the Entity's status and also of the objects dependent on cascade become detached.

• For the new, detached, or removed status, it throws out the exception.
• For the managed status, it restores all the changes from the database and refreshes all objects dependent on the cascade.

There are two types of cache in JPA:

• First-level cache: Data is cached from a single transaction.
• Second-level transaction: Data is cached from more than one transaction.

The access type for an entity class, embeddable, superclass, or individual attributes is defined by it. This defines the way JPA refers to entity attributes such as class properties or class fields having setters and getters.

The simplest type of mapping of data on a column of the database is indicated by the basic annotation.

Also, the fetch field access strategy, as well as the requirement of the field, can be specified in the annotation parameters.

The six types of locks are listed below in the ascending order of their reliability:

• NONE
• OPTIMISTIC
• OPTIMISTIC_FORCE_INCREMENT
• PESSIMISTIC_READ
• PESSIMISTIC_WRITE
• PESSIMISTICI

The following five options are there:

• ALL
• NONE
• ENABLE_SELECTIVE
• DISABLE_SELECTIVE
• UNSPECIFIED

The Metamodel interface is used by JPA for this purpose.

We can obtain this interface's object using the method of getMetamodel from an EntityManger or EntityMangerFactory.

The implicit polymorphism strategy is present in Hibernate but it is not present in JPA.

• JPQL is almost similar to SQL, but the names of entity classes and attributes are used instead of the database columns.
• Also, the data types of entity attributes are used by the query parameters instead of database fields.
• There is automatic polymorphism in JPQL, unlike SQL. KEY, TREAT, VALUE, MAP, and ENTRY are some of the unique functions of JPQL.

This means that regardless of the inheritance strategy, the objects of all the descendant classes are returned in each entity request.

We can use the TYPE function in the where condition for turning polymorphism off in JPQL.