Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Banish Your Resistance to Persistence with the EJB 3.0 Persistence API : Page 2

With the 3.0 version of EJB, Java's guardians have endeavored to make persistence a gentler beast that borrows the best from other ORM frameworks that have long curried favor with the community. Now, learn how to use the new spec, along with JBoss and Maven, to persist Java objects to a relational database.




Full Text Search: The Key to Better Natural Language Queries for NoSQL in Node.js

Introducing EJB 3.0 Persistence
The EJB 3.0 specification defines a persistence API that is modeled after successful approaches to Object Relational Mapping (ORM) such as Hibernate, JDO, and TopLink. This approach stands in contrast to the approach taken in the introduction of entity beans in EJB 1.0 where the specification preceded industry consensus.

This third major release of the EJB specification is exciting because it attempts to standardize the successful, yet diverse, array of ORM tools. This standardization is not intended to replace existing tools or to discourage innovation in this arena, but to provide a commonly agreed upon set of standards to support vendor tooling and the stability associated with Sun and JCP acceptance. This is often important to large IT organizations concerned with the long-term viability of the technologies they adopt.

This new approach to developing persistent entities is radically different then the entity bean approach taken in prior versions of the EJB specification. This new approach is characterized by:

  • Plain java objects (POJO)—Persistent entities are simple Java objects and have no dependencies on an EJB-specific API.
  • Metadata annotations—The mapping configuration is defined by source-level metadata annotations. An XML descriptor may still be used as an alternative or to override annotations.
  • Configuration by exception—To simplify configuration the specification takes the approach of assuming reasonable defaults and requiring the programmer to only define configuration information when it is necessary to override these settings.
  • Optional container—The persistence API defined in the EJB 3.0 specification is designed to run both inside and outside of an EJB container.
Introducing Entities
The specification defines entities as lightweight persistent domain objects. This means an entity is simply a POJO from your domain that you desire to persist in a data store of some type. The requirements of an entity are very minimal. To qualify as an entity a class must:
  • Be annotated with the @Entity annotation.
  • Have a default (no argument) constructor.
  • Have a primary key.
  • Must not be final and must have no final methods.
  • Instance variables holding the state of the entity must be private, protected, or have package visibility.
  • If the entity is to be detached then the class must implement the Serializable interface.
Entities are plain Java objects and as such may contain references to other POJOs and persistent entities. An entity class may be abstract and can extend other entity or non-entity classes.

Basic Mapping
In order for entities to be persisted the state of each entity must be mapped to the underlying data source. This is typically done through metadata annotations that map fields in the entity to tables and columns in the data store. You have two options (access types) regarding how you define this mapping:

  • Field access—All non-transient instance variables are persisted. You annotate the instance variables directly to override default mapping settings.
  • Property access—All public and protected, non-transient properties are persisted. You annotate the getter method to override default mapping settings.
You can choose which access type you wish to be used for each entity through the access attribute of the @Entity annotation. The example below illustrates how to specify field-level access:

@Entity(access = AccessType.FIELD) public class MusicOrder implements Serializable { ... }

By default, property-level access is assumed for persistent entities.

You can specify a variety of settings to control how the entity is persisted. For example, you can specify which table a particular entity is persisted to through the @Table annotation, which can be applied at the class level:

@Entity(access = AccessType.FIELD) @Table(name = "musicorder") public class MusicOrder implements Serializable { ... }

And you can specify which column any particular field or property is persisted to through the @Column annotation:

@Entity(access = AccessType.FIELD) @Table(name = "musicorder") public class MusicOrder implements Serializable { @Column(name = "desc") private String description = "test"; ... }

If you would like a particular to field to not be persisted then all you have to do is annotate it with the @Transient annotation to indicate that the data in the field need not be saved:

@Entity(access = AccessType.FIELD) @Table(name = "musicorder") public class MusicOrder implements Serializable { @Column(name = "desc") private String description = "test"; @Transient private List<Product> products; ... }

However, in order to make the example above complete we must define a primary key and optionally provide information about how this identifier is to be determined and mapped. The following example shows a simple primary key where the responsibility for assigning unique identifiers is delegated to the underlying database:

@Entity(access = AccessType.FIELD) @Table(name = "musicorder") public class MusicOrder implements Serializable { @Id(generate = GeneratorType.AUTO) private long orderID; @Column(name = "desc") private String description = "test"; @Transient private List<Product> products; ... }

As shown above the @Id annotation allows you to configure the strategy used to determine the value of the identity field. Other options include TABLE, SEQUENCE, AUTO, and NONE. For more information on these other options consult the EJB 3.0 specification.

In order to convert this example to work with property-level access instead of field-level access all you would need to do would be to change the access attribute of the @Entity attribute to AccessType.PROPERTY and move the @Id, @Column, and @Transient annotations to their respective getter methods.

At this point you have created an EJB 3.0 entity class that contains enough information for the persistence engine to store MusicOrder objects. Next you need to use the persistence framework API to cause persistent entities to be created, updated, and deleted.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date