January 27, 2021
Hot Topics:

Developing Entity Beans

  • By Saleem Siddiqui, Michael Landy, & Jeff Swisher
  • Send Email »
  • More Articles »

EJB 2.0 Versus EJB 1.1

There were two large problems with the EJB 1.1 specification as it related to entity beans. The EJB 2.0 specifications focused on these two problems:

  • It was difficult to build coarse-grained entity beans.

  • Finder methods lacked portability.

The Enterprise JavaBean 2.0 specifications have provided a number of new features to fill some of the gaps found in the EJB 1.1 specification. Table 23.1 presents some of the problems found after many applications were written using the EJB 1.1 specification and how the 2.0 specification resolves them.

Table 1 EJB 1.1 Specification Versus EJB 2.0 Specifications

EJB 1.1 Problem

EJB 2.0 Solution

No good pattern to represent dependent objects within an entity bean

The introduction of local interfaces, which allow for modeling of dependent objects as another bean but still allow for good performance.

Load-on-demand and dirty checking of data

EJB 2.0 CMP has abstract methods available for the implementation of load-on-demand and dirty checking.

No portable way to ensure the contents of a collection within a container's persistence strategy

The EJB container maintains collection classes that simplify the object-to-relational mapping.

Data-aliasing contention created when two or more entities reference the same dependent object

Dependent objects are managed as entity objects by the container. The container then manages the state of the entity component. This ultimately allows for synchronization within the transaction with multiple entities being represented as multiple aliases.

No portable implementation of finder methods

A portable query language was implemented based on a subset of SQL.

With these new features, most of which have been added to container managed persistence, entity beans have become extremely powerful and efficient. A developer can simply model most if not all of the persistence requirements within JBuilder allowing you to work on your business methods rather than plumbing.

Primary Keys

As we have looked at entity beans to this point, the key consideration is that relational data is represented in the object world. Therefore, just as the relational world represents a unique instance of data with a primary key, you must do the same in the object world. This special class is called the primary key. Its sole purpose is to uniquely identify an instance of an entity bean. In other words, the primary key class contains all the information required to find an entity within the persistent data store. To accomplish this successfully, a number of rules must be followed:

  • The primary key instances must be any legal type in RMI/IIOP. In other words, it must be serializable.

  • It must provide a hashcode() and equals() method.

  • It must uniquely identify a single instance of the data stored within the persistent data store. For example, the primary key of the table is probably a good primary key for the entity.

  • In container managed persistence, the class must have a constructor that takes no arguments. Because the container is responsible for creating instances, it must have the capability to create a primary key class.

Page 2 of 3

This article was originally published on July 17, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

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