Persisting Objects in EJB 3

It is a different world altogether when you talk of persistence in the older

EJB specifications. The Entity Beans were truly heavyweight and the business

logic followed more of a procedural design rather than object-oriented one.

There were many reasons for this, one of them being the monolithic nature of the

EJBs themselves in the earlier specification. The specification had quite a few

limitations, for instance, starting with the configurations themselves was quite

tedious and persistence using the earlier specification was not an easy task

either. The only way you could use persistence for a session bean is by using a

'Session Façade'. 

Similarly, the entity beans did not provide for inheritance, a factor that

would invariably exist amongst entities in a real life scenario database causing

problems in persisting such objects. The new specification eases persistence by

incorporating important changes such as support for inheritance. Other important

improvements are the use of dependency injection as a mechanism in place of JNDI

lookups.

By default, in EJB 3, the JNDI name is derived from the field type and the

setter methods and dependency injection encapsulates the look-up process.

Eliminating JNDI lookups not only simplifies session beans and message-driven

beans, but also reduces dependency on an application server's environment. It

also includes standardized OR mapping mechanism, and allows queries to be

created both statically and dynamically. In this article, we delve into a few of

these features that can ease the pain of implementing the business logic and

also persisting entities.

Sample Entity Bean



Let's first code a sample entity bean that represents an employee in an
organization. We'll make an EJB 3 Entity Bean, which will have most of the

properties defined using annotations. The code for the bean is as follows.

@Entity(access=AccessType.FIELD)



public class Employee {


private Long id;


private String name;


private String designation;


private String grade;


private Address address;


public Employee() {


}


@Id


@GeneratedValue(strategy = GenerationType.AUTO)


public Long getId() {


return id;


}


public void setId(Long id) {


this.id = id;


}


...


}

The bean definition is simple and it represents an employee. However as per

the JSR-220, there are a lot more features at your disposal to harness the

improved design. For example, the Entity Bean supports inheritance, polymorphic

association and polymorphic queries also. As far as persistence is concerned, we

can define persistence properties right in the source code of the bean itself.

In our sample bean, the annotation '@Entity(access=AccessType. FIELD)' means

that the EJB container has to map the bean's field rather than the properties

for persistence. You can also map the properties for persistence by changing the

value of 'access' attribute to 'AccessType.PROPERTIES'. Similarly, you

can define



relationships for mappings of classes being used as a field in this class. For
example, our sample bean can define '@ManyToOne' annotation for 'Address'.

Address here is a separate class mapped to a relational table. These annotations

work in the same manner as the mappings defined using OR mapping documents if

using Hibernate (the HiBernate Mappings or HBMs). You can also avoid mappings

for a certain field/property by using the '@Transient' annotation. The

persisted field/properties can even be a Collection, or any of the following

collection interfaces, namely Set, List and Map. The entity is then created

using the good old 'new' operator. While this entity is not persistent by

default, the persistence in EJB 3 is handled by 'EntityManager' and related

interfaces in the persistence API.

The logical architecture of the new EJB 3 persistence API lets you manage persistence while preserving an object-oriented pattern

The Entity Manager



This interface lies at the heart of the persistence API in EJB 3. The Entity
Manager instance in an application is always associated with a 'persistence

context' within which the entity instances and their lifecycle are managed.

The Entity Manager interface declares all the methods for interaction with the

persistence context. Other than this, the interface is used to create and remove

persistence entities, find entities using their primary key and query over the

entities. Here's a sample snippet of the use of EntityManager Interface.

@Stateless() // specifies a stateless entity

bean.



public class EmployeeSessionBean implements com.pcq.EmployeeSessionLocal {


@PersistenceContext EntityManager eManager;


public void makeIncentive(int empID, PayTransact pTrans){


Employee emp = eManager.find(Employee.class,int empID);


emp.getIncetives().add(amt);


pTrans.setTrans(emp);


}}

The '@PersistenceContext' annotation describes the dependency on the

EntityManager persistence context. The annotation has a 'PersistenceContextType'

element that defines the scope of dependency in the given application. The

element has two values Extended and Transaction-the former defines an extended

scope for the context (one that scopes beyond a transaction) while the latter

defines a transaction-scoped context and is the default value. We used the 'find

()' method here that locates a particular entity based on the primary key

specified. Other methods in the interface are 'persist (Object entity)' that

makes an entity instance persistent and managed, merge (T entity) that merges

the state of the given entity to the current persistence context. The remove

(Object entity) method removes the entity instance from the context, flush ( )

synchronizes the context to the database and refresh (Object entity) method

refreshes the state of the entity from the database by making all the changes in

the database that exist in the entity. All of these are to be invoked from

within a 'transaction-scoped' context otherwise the'javax.persistence.

TransactonRequieredException' is thrown.

The Query Interface



The query API is represented by this interface in EJB 3, and allows static and
dynamic queries and named parameter binding also. Lets look into how this

interface can be put into use in your code. The following method queries about

all employees of a particular designation.

public List getEmployeeNames(String desig){



return eManager.createQuery(“select a from Employee a where a.designation like
:d”)



.setParamter(“d”,desig)


.getResultList();


}

There are many ways of executing the same queries drilling down to specific

features supported by the interface. A named query executing the same results

can be implemented by using the '@NamedQuery' annotation as follows.

@NamedQuery{



name=”findNameOfEmployeesWithDesig”,


query=” select a from Employee a where a.designation like :d”


}


You can then use it in the 'getEmployeeName()' method as follows.


public List getEmployeeNames(String design){


return eManager.createQuery(findNameOfEmployeesWithDesig)


.setParamter(“d”,design)


.getResultList();


}

You can also specify the mapping of the result of a native SQL query in your

application. The persistence API defines the '@SetResultSetMapping' and '@SetResultSetMappings'

for this purpose. The former represents a single mapping whereas the latter can

be used for multiple mappings.

In conclusion



The API incorporates major changes in persistence as compared to the previous
versions allowing developers to write in an object-oriented pattern rather than

the 'transaction script' or procedural type code as mentioned before. While

frameworks such as Hibernate or JDO (Java Data Objects) are always available for

use, you can still find good usage for the new persistence API in EJB 3.