There are many object relational mapping (ORM) tools available in licensed as well as freeware category. You must have heard Hibernate and Toplink in open source technologies. These technologies offer their own implementation to interact with database. Though the implementation varies, the underlying business is same – map an object in middle tier with a relation in database. Java Persistence API (JPA) selects the necessary and best out of these open source frameworks, and defines a specification so that the application server vendors can comply with that. Also, the open source technologies are registering their support to with JPA. In this article, we understand the terminologies of JPA, and how the middle tier object is linked with a database table. If you have already worked on any ORM tool, then this will be a cake walk for you, just that there will be difference of words.

Interaction with Database:

Whenever any application interacts with database, it has to go through following steps -

• Make a connection with database
• Transform the middle tier objects into query and persist in database and vice versa
• Manage the interaction session with database

Each of these step needs to be implemented by a developer by choosing one of the multiple options available. Let us take each of above step, and see what all options we have without JPA.

Make a Connection to Database:

Basically, it is opening a session with database using appropriate driver, connection url, user and password. Complexity of this does not end here. Connection is actually a resource, and we need to be careful while dealing with it. Hence there are multiple ways of creating and managing connection.

• Using JDBC API programmatically to manage the connections (pool)
• Using application server data sources
• Using session factories provided by ORM tools

Transform Middle Tier Objects:

There are two options for this – since ages, we have been converting the object data into queries and then firing those queries on database. With ORM tools availability, we started mapping the table columns with object attributes (along with relations) in xml formats. ORM tools used these xmls and generated queries for us. No need to learn SQL and other database languages.

Manage the Session with Database:

In other words, manage transactions. Use JTA, application server support or the ORM tool support to transaction management. Frameworks like Spring also provide container to do the data access business as well as manage transactions declaratively.

 

How JPA Wants Us to Do Above Steps?

As stated above, JPA selects standard and best practices from above set to interact with a database.

• Make a connection with database: Configurable, using implementation of EntityManager through a container provider
• Transform middle tier objects: Use annotations
• Manage session with database: Use application server support or container provider support to transaction management

If I want to draw a simple picture of this, this is how it will be

 

Let us take each term to understand significance of it and requirements of it.

Entity:

• Non final class representing DB table(s)
• Annotated with javax.persistence.Entity
• Either attributes or getter/setter methods with public/protected scope
• Implements Serializable interface if to be transported across JVMs (remotly)
• Has public/protected no argument constructor
• Uses supported data types for attributes
• Defines primary key using a property annotated by javax.persistence.Id, or composite key using a class
• Abstract class can be declared as an entity
• Super classes can be annotated as a MappedSuperClass when those are not having decoration Entity

EntityManager:

• Implementation of javax.persistence.EntityManager
• Manages connection with database
• Manages persistence and retrieval of entities from database
• Injected using javax.persistence.PersistenceContext annotation
• Can be container-managed or application-managed
• Supports query execution

Persistence Unit:

• Includes all instances of entities that are managed by all EntityManagers in application
• persistence.xml defined in META-INF directory of ear/jar defines one or more persistence units

Multiplicity in Entity Relationships:

• One to one: Each entity instance is related to one instance of other entity. This relations is annotated using javax.persistence.OneToOne annotation.
• One to many: One instance of an entity can be related to many instances of other entity. This relation is annotated using javax.persistence.OneToMany.
• Many to one: Multiple instances of one entity can be related to one instance of other entity. This relation is annotated using javax.persistence.ManyToOne.
• Many to Many: Entity instances of one entity can be related to many instances of other entity. This relation is annotated using javax.persistence.ManyToMany.

Directional Relationship:

• Unidirectional: In this relation only one entity has field/property that refers to other entity.
• Bidirectional: In this relation both the entities contain field/property that refers to other entity. Thus the owner entity also contains foreign key reference to the other entity.

Cascade Deletes:

Cascade is important in case of propagation of delete operation in relations. Specifying cascade=REMOVE would be required in case of OneToOne and OneToMany relations.

 

Mapping Strategies:

When we have inheritance amongst the entity classes, i.e. the root class of hierarchy is decorated with javax.persistence.Inheritance annotation, then there are three mapping strategies. The strategy applicable is defined using javax.persistence.InheritenceType enumeration. The possible values are SINGLE_TABLE, JOINED, TABLE_PER_CLASS. The default strategy is SINGLE_TABLE.

• A single table per hierarchy: All classes in the inheritance hierarchy are persisted in single database table. The data is differentiated using discriminator type (column).
• Table per concrete class: In this strategy there is table per concrete class. Means there is table for the parent class as well as all child classes. In this approach, the data gets duplicated.
• Joined sub class: In this strategy there is a table which holds data from the parent class, and each sub class has a separate table. There is foreign key in each of the sub table.

 

 

More Related Posts in JEE, Tech Notes