Home > Articles > Programming > Java

This chapter is from the book

This chapter is from the book

Implementing a BMP Entity Bean

Implementing an Entity bean involves providing an implementation for the methods of the javax.ejb.EntityBean, corresponding methods for each method in the local-home interface, and a method for each method in the local interface.

Implementing javax.ejb.EntityBean

The setEntityContext() method is a good place to perform JNDI lookups, for example to acquire a JDBC DataSource reference. Listing 6.4 shows how this is done for the JobBean code.

Listing 6.4—JobBean.setEntityContext() Method

  1: package data;
  3: import javax.ejb.*;
  4: import javax.naming.*;
  5: import javax.sql.*;
  6: // imports omitted
  8: public class JobBean implements EntityBean
  9: {
 10:   public void setEntityContext(EntityContext ctx) {
 11:     this.ctx = ctx;
 12:     InitialContext ic = null;
 13:     try {
 14:       ic = new InitialContext();
 15:       dataSource = (DataSource)ic.lookup("java:comp/env/jdbc/Agency");
 16:      skillHome = (SkillLocalHome)
 17:      locationHome = (LocationLocalHome)
 18:      customerHome = (CustomerLocalHome)
 19:    }
 20:    catch (NamingException ex) {
 21:      error("Error looking up depended EJB or resource",ex);
 22:      return;
 23:    }
 24:  }	
 26:   private Context ctx;
 27:   private DataSource dataSource
 29:   // code omitted
 30: }

The unsetEntityContext() method (not shown) usually just sets these fields to null.

The ejbLoad() and ejbStore() methods are responsible for synchronizing the bean's state with the persistent data store. Listing 6.5 shows these methods for JobBean.

Listing 6.5—JobBean's ejbLoad() and ejbStore() Methods

  1: package data;
  3: import javax.ejb.*;
  4: import java.sql.*;
  5: // imports omitted
  7: public class JobBean implements EntityBean
  8: {
  9:   public void ejbLoad(){
 10:     JobPK key = (JobPK)ctx.getPrimaryKey();
 11:     Connection con = null;
 12:     PreparedStatement stmt = null;
 13:     ResultSet rs = null;
 14:     try {
 15:       con = dataSource.getConnection();
 16:       stmt = con.prepareStatement(
         "SELECT description,location 
          FROM Job
          WHERE ref = ? AND customer = ?");
 17:       stmt.setString(1, key.getRef());
 18:       stmt.setString(2, key.getCustomer());
 19:       rs = stmt.executeQuery();
 20:       if (!rs.next()) {
 21:         error("No data found in ejbLoad for " + key, null);
 22:       }
 23:       this.ref = key.getRef();
 24:       this.customer = key.getCustomer();
 25:       this.customerObj = 
         customerHome.findByPrimaryKey(this.customer); // derived
 26:       this.description = rs.getString(1);
 27:       String locationName = rs.getString(2);
 28:       this.location = (locationName != null) ? 
         locationHome.findByPrimaryKey(locationName) : null;
 29:       // load skills
 30:       stmt = con.prepareStatement(
         "SELECT job, customer, skill 
          FROM JobSkill 
          WHERE job = ? AND customer = ? 
          ORDER BY skill");
 31:       stmt.setString(1, ref);
 32:       stmt.setString(2, customerObj.getLogin());
 33:       rs = stmt.executeQuery();
 34:       List skillNameList = new ArrayList();
 35:       while (rs.next()) {
 36:         skillNameList.add(rs.getString(3));
 37:       }
 38:       this.skills = skillHome.lookup(skillNameList);
 39:     }
 40:     catch (SQLException e) {
 41:       error("Error in ejbLoad for " + key, e);
 42:     }
 43:     catch (FinderException e) {
 44:       error("Error in ejbLoad (invalid customer or location) for " 
            + key, e);
 45:     }
 46:     finally {
 47:       closeConnection(con, stmt, rs);
 48:     }
 49:   }
 51:   public void ejbStore(){
 52:     Connection con = null;
 53:     PreparedStatement stmt = null;
 54:     try {
 55:       con = dataSource.getConnection();
 56:       stmt = con.prepareStatement(
         "UPDATE Job 
          SET description = ?, location = ? 
          WHERE ref = ? AND customer = ?");
 57:       stmt.setString(1, description);
 58:       if (location != null) {
 59:         stmt.setString(2, location.getName());
 60:       } else {
 61:         stmt.setNull(2, java.sql.Types.VARCHAR);
 62:       }
 63:       stmt.setString(3, ref);
 64:       stmt.setString(4, customerObj.getLogin());
 65:       stmt.executeUpdate();
 66:       // delete all skills
 67:       stmt = con.prepareStatement(
         "DELETE FROM JobSkill 
          WHERE job = ? and customer = ?");
 68:       stmt.setString(1, ref);
 69:       stmt.setString(2, customerObj.getLogin());
 70:       stmt.executeUpdate();
 71:       // add back in all skills
 72:       for (Iterator iter = getSkills().iterator(); iter.hasNext(); ) {
 73:         SkillLocal skill = (SkillLocal)iter.next();
 74:         stmt = con.prepareStatement(
           "INSERT INTO JobSkill (job,customer,skill) 
            VALUES (?,?,?)");
 75:         stmt.setString(1, ref);
 76:         stmt.setString(2, customerObj.getLogin());
 77:         stmt.setString(3, skill.getName());
 78:         stmt.executeUpdate();
 79:       }
 80:     }
 81:     catch (SQLException e) {
 82:       error("Error in ejbStore for " + ref + "," + customer, e);
 83:     }
 84:     finally {
 85:       closeConnection(con, stmt, null);
 86:     }
 87:   }
 88:   // code omitted
 89: }

In the ejbLoad() method, the JobBean must load its state from both the Job and JobSkill tables, using the data in the JobSkill table to populate the skills field. In the ejbStore() method, the equivalent updates to the Job and JobSkill tables occur.

Of course, there is the chance that when the bean comes to save itself, the data could have been removed. This would happen if some user manually deleted the data; there is nothing in the EJB specification to require that an Entity bean "locks" the underlying data. In such a case, the bean should throw a javax.ejb.NoSuchEntityException; in turn, this will be returned to the client as some type of java.rmi.RemoteException. This was mentioned briefly yesterday, so look back to refresh your memory if needed. And remember, you will be learning more about exception handling and transactions on Day 8.


To keep the case study as small and understandable as possible, the error handling in JobBean is slightly simplified. In Listing 6.5, the code will throw an EJBException (rather than NoSuchEntityException) from ejbLoad() if the data has been removed. In ejbStore(), it doesn't actually check to see if any rows were updated, so no exception would be thrown.

More complex beans can perform other processing within the ejbLoad() and ejbStore() methods. For example, the data might be stored in some denormalized form in a relational database, perhaps for performance reasons. The ejbStore() method would store the data in this de-normalized form, while the ejbLoad() methods would effectively be able to re-normalize the data on-the-fly. The client need not be aware of these persistence issues.

Another idea: these methods could be used to handle text more effectively. The EJB specification suggests compressing and decompressing text, but they could also perhaps do searches for keywords within the text, and then redundantly store these keywords separately, or the data might be converted into XML format.

As noted earlier today, there is usually very little or nothing to be done when an Entity bean is passivated or activated. Listing 6.6 shows this.

Listing 6.6—JobBean's ejbActivate() and ejbPassivate() Methods

  1: package data;
  3: import javax.ejb.*;
  4: // imports omitted
  6: public class JobBean implements EntityBean
  7: {
  8:   public void ejbPassivate(){
  9:     ref = null;
 10:     customer = null;
 11:     customerObj = null;
 12:     description = null;
 13:     location = null;
 14:   }
 16:   public void ejbActivate(){
 17:   }
 19:   // code omitted
 20: }

Implementing the Local-Home Interface Methods

The implementation of ejbCreate() and ejbPostCreate() for the JobBean is shown in Listing 6.7.

Listing 6.7—JobBean's ejbCreate() and ejbPostCreate() Methods

  1: package data;
  3: import javax.ejb.*;
  4: import javax.sql.*;
  5: // imports omitted
  7: public class JobBean implements EntityBean
  8: {
  9:   private String ref;
 10:   private String customer;
 11:   private String description;
 12:   private LocationLocal location;
 13:   private CustomerLocal customerObj; // derived
 14:   private List skills;  // vector field; list of SkillLocal ref's.
 16:   public String ejbCreate (String ref, String customer) 
            throws CreateException {
 17:     // validate customer login is valid.
 18:     try {
 19:       customerObj = customerHome.findByPrimaryKey(customer);
 20:     } catch (FinderException ex) {
 21:       error("Invalid customer.", ex);
 22:     }
 23:     JobPK key = new JobPK(ref, customer);
 24:     try {
 25:       ejbFindByPrimaryKey(key);
 26:       throw new CreateException("Duplicate job name: " + key);
 27:     }
 28:     catch (FinderException ex) { }
 29:     Connection con = null;
 30:     PreparedStatement stmt = null;
 31:     try {
 32:       con = dataSource.getConnection();
 33:       stmt = con.prepareStatement(
         "INSERT INTO Job (ref,customer) 
          VALUES (?,?)");
 34:       stmt.setString(1, ref);
 35:       stmt.setString(2, customerObj.getLogin());
 36:       stmt.executeUpdate();
 37:     }
 38:     catch (SQLException e) {
 39:       error("Error creating job " + key, e);
 40:     }
 41:     finally {
 42:       closeConnection(con, stmt, null);
 43:     }
 44:     this.ref = ref;
 45:     this.customer = customer;
 46:     this.description = description;
 47:     this.location = null;
 48:     this.skills = new ArrayList();
 49:     return key;
 50:   }
 52:   public void ejbPostCreate (String name, String description) {}
 53: }

This particular implementation validates that the customer exists (jobs are identified by customer and by a unique reference), and it also makes sure that the full primary key does not already exist in the database. If it does, the BMP bean throws a CreateException. If it doesn't (represented by the ejbFindByPrimaryKey() call throwing a FinderException), the method continues.

An alternative implementation would have been to place a unique index on the Job table within the RDBMS and then to catch the SQLException that might be thrown if a duplicate is attempted to be inserted.


There is a race condition here. It's possible that another user could insert a record between the check for duplicates and the actual SQL INSERT. The ejbCreate() method is called within a transaction; changing the RDBMS isolation level (in a manner specified by the EJB container) would eliminate this risk, although deadlocks could then occur. Transactions, isolation levels, and deadlocks are discussed further on Day 8.

Note that the skills field is set to an empty ArrayList. This holds a list of SkillLocal references, this being the local interface to the Skill bean. Of course, for a newly created Job bean, this list is empty. The decision for the skills field to hold references to SkillLocal objects rather than, say, just Strings holding the skill names, was taken advisedly. If the skill name is used (that is, the primary key of a skill), finding information about the skill would require extra steps. Perhaps more compellingly, this is also the approach taken for CMP beans and container-managed relationships, discussed in detail tomorrow.

Also noteworthy is the customerObj field. The Job, when created, is passed just a String containing the customer's name. In other words, this is a primary key to a customer. The customerObj field contains a reference to the parent customer bean itself by way of its CustomerLocal reference.

Both the skills and the customerObj fields illustrate (for want of a better phrase) bean-managed relationships. For the skills field, this is a many-to-many relationship, from Job to Skill. For the customerObj field, this is a many-to-one relationship from Job to Customer.

As for the stateful Session beans that you learned about yesterday, the ejbCreate() and ejbPostCreate() methods both correspond to a single method called create() in the bean's local-home interface. The list of arguments must correspond. Again, as for Session beans, it is possible for there to be more than one create method with different sets of arguments, or indeed the createXXX() method naming convention can be used instead of overloading the method name of create().

The ejbRemove() method is the opposite of the ejbCreate() method; it removes a bean's data from the persistent data store. Its implementation for JobBean is shown in Listing 6.8.

Listing 6.8—JobBean's ejbRemove() Method

  1: package data;
  3: import javax.ejb.*;
  4: import javax.naming.*;
  5: // imports omitted
  7: public class JobBean implements EntityBean
  8: {
  9:   public void ejbRemove(){
 10:     JobPK key = (JobPK)ctx.getPrimaryKey();
 11:     Connection con = null;
 12:     PreparedStatement stmt1 = null;
 13:     PreparedStatement stmt2 = null;
 14:     try {
 15:       con = dataSource.getConnection();
 16:       stmt1 = con.prepareStatement(
         "DELETE FROM JobSkill 
          WHERE job = ? and customer = ?");
 17:       stmt1.setString(1, ref);
 18:       stmt1.setString(2, customerObj.getLogin());
 19:       stmt2 = con.prepareStatement(
         "DELETE FROM Job 
          WHERE ref = ? and customer = ?");
 20:       stmt2.setString(1, ref);
 21:       stmt2.setString(2, customerObj.getLogin());
 22:       stmt1.executeUpdate();
 23:       stmt2.executeUpdate();
 24:     }
 25:     catch (SQLException e) {
 26:       error("Error removing job " + key, e);
 27:     }
 28:     finally {
 29:       closeConnection(con, stmt1, null);
 30:       closeConnection(con, stmt2, null);
 31:     }
 32:     ref = null;
 33:     customer = null;
 34:     customerObj = null;
 35:     description = null;
 36:     location = null;
 37:   }
 38:   // code omitted
 39: }

Each of the finder methods of the local-home interface must have a corresponding method in the bean. By way of example, Listing 6.9 shows two of the (three) finder methods for the JobBean.

Listing 6.9—JobBean's Finder Methods

  1: package data;
  3: import javax.ejb.*;
  4: import java.sql.*;
  5: import java.util.*;
  6: // imports omitted
  8: public class JobBean implements EntityBean
  9: {
 10:   public JobPK ejbFindByPrimaryKey(JobPK key) throws FinderException {
 11:     Connection con = null;
 12:     PreparedStatement stmt = null;
 13:     ResultSet rs = null;
 14:     try {
 15:       con = dataSource.getConnection();
 16:       stmt = con.prepareStatement(
         "SELECT ref 
          FROM Job 
          WHERE ref = ? AND customer = ?");
 17:       stmt.setString(1, key.getRef());
 18:       stmt.setString(2, key.getCustomer());
 19:       rs = stmt.executeQuery();
 20:       if (!rs.next()) {
 21:         throw new FinderException("Unknown job: " + key);
 22:       }
 23:       return key;
 24:     }
 25:     catch (SQLException e) {
 26:       error("Error in findByPrimaryKey for " + key, e);
 27:     }
 28:     finally {
 29:       closeConnection(con, stmt, rs);
 30:     }
 31:     return null;
 32:   }
 34:   public Collection ejbFindByCustomer(String customer) 
              throws FinderException {
 35:     Connection con = null;
 36:     PreparedStatement stmt = null;
 37:     ResultSet rs = null;
 38:     try {
 39:       con = dataSource.getConnection();
 40:       stmt = con.prepareStatement(
         "SELECT ref, customer 
          FROM Job 
          WHERE customer = ? 
          ORDER BY ref");
 41:       stmt.setString(1, customer);
 42:       rs = stmt.executeQuery();
 43:       Collection col = new ArrayList();
 44:       while (rs.next()) {
 45:         String nextRef = rs.getString(1);
 46:         String nextCustomer = rs.getString(2);
 47:         // validate customer exists
 48:         CustomerLocal nextCustomerObj = 
 49:         col.add(new JobPK(nextRef, nextCustomerObj.getLogin()));
 50:       }
 51:       return col;
 52:     }
 53:     catch (SQLException e) {
 54:       error("Error in findByCustomer: " + customer, e);
 55:     }
 56:     catch (FinderException e) {
 57:       error("Error in findByCustomer, invalid customer: " + customer, e);
 58:     }
 59:     finally {
 60:       closeConnection(con, stmt, rs);
 61:     }
 62:     return null;
 63:   }
 65:  // code omitted
 66: }

The implementation of the ejbFindByPrimaryKey() method might seem somewhat unusual; it receives a primary key, and then returns it. Of course, it has validated that an entity exists for the given primary key; if there were none, a javax.ejb.ObjectNotFoundException would be thrown. The implementation of ejbFindByCustomer() is straightforward enough.

The Job bean defines a home method, namely deleteByCustomer(), and the corresponding method in the JobBean class is ejbHomeDeleteByCustomer(), as shown in Listing 6.10.

Listing 6.10—JobBean.ejbHomeDeleteByCustomer() Home Method

  1: package data;
  3: import javax.ejb.*;
  4: import java.sql.*;
  5: import java.util.*;
  6: // imports omitted
  8: public class JobBean implements EntityBean
  9: {
 10:   public void ejbHomeDeleteByCustomer(String customer) {
 11:     Connection con = null;
 12:     PreparedStatement stmt2 = null;
 13:     PreparedStatement stmt1 = null;
 14:     try {
 15:       con = dataSource.getConnection();
 16:       stmt1 = con.prepareStatement(
         "DELETE FROM JobSkill 
          WHERE customer = ?");
 17:       stmt2 = con.prepareStatement(
         "DELETE FROM Job 
          WHERE customer = ?");
 18:       stmt1.setString(1, customer);
 19:       stmt2.setString(1, customer);
 20:       stmt1.executeUpdate();
 21:       stmt2.executeUpdate();
 22:     }
 23:     catch (SQLException e) {
 24:       error("Error removing all jobs for " + customer, e);
 25:     }
 26:     finally {
 27:       closeConnection(con, stmt1, null);
 28:       closeConnection(con, stmt2, null);
 29:     }
 30:   }
 31:  // code omitted
 32: }

Implementing the Local Interface Methods

Each of the methods in the local interface has a corresponding method in the bean itself. The corresponding methods for JobBean are shown in Listing 6.11.

Listing 6.11—Business Methods of JobBean Correspond to the Methods of the Local Interface

  1: package data;
  3: import java.rmi.*;
  4: import javax.ejb.*;
  5: // imports omitted
  7: public class JobBean implements EntityBean
  8: {
  9:   public String getRef() {
 10:     return ref;
 11:   }
 12:   public String getCustomer() {
 13:     return customer;
 14:   }
 15:   public CustomerLocal getCustomerObj() {
 16:     return customerObj;
 17:   }
 18:   public String getDescription() {
 19:     return description;
 20:   }
 21:   public void setDescription(String description) {
 22:     this.description = description;
 23:   }
 24:   public LocationLocal getLocation() {
 25:     return location;
 26:   }
 27:   public void setLocation(LocationLocal location) {
 28:     this.location = location;
 29:   }
 30:   /** returns (copy of) skills */
 31:   public Collection getSkills() {
 32:     return new ArrayList(skills);
 33:   }
 34:   public void setSkills(Collection skills) {
 35:     // just validate that the collection holds references to SkillLocal's
 36:     for (Iterator iter = getSkills().iterator(); iter.hasNext(); ) {
 37:       SkillLocal skill = (SkillLocal)iter.next();
 38:     }
 39:     // replace the list of skills with that defined.
 40:     this.skills = new ArrayList(skills);
 41:   }
 42:  // code omitted
 43: }

The getSkills() and setSkills() methods bear closer inspection. The getSkills() method returns a copy of the local skills field because, otherwise, the client could change the contents of the skills field without the JobBean knowing. This isn't an issue that would have arisen if the interface to JobBean was remote, because a copy would automatically have been created. Turning to the setSkills() method, this checks to make sure that the new collection of skills supplied is a list of SkillLocal references. This is analogous to the setLocation() method that was discussed; the Job Entity bean is enforcing referential integrity with the Skill Entity bean.

Generating IDs

Sometimes an Entity bean already has a field(or fields) that represent the primary key, but at other times, the set of fields required may just be too large. Alternatively, the obvious primary key may not be stable in the sense that its value could change over the lifetime of an entity—something prohibited by the EJB specification. For example, choosing a (lastname, firstname) as a means of identifying an employee may fail if a female employee gets married and chooses to adopt her husband's surname.

In these cases, it is common to introduce an artificial key, sometimes known as a surrogate key. You will be familiar with these if you have ever been allocated a customer number when shopping online. Your social security number, library card number, driver's license, and so on may well be just a pretty meaningless jumble of numbers and letters, but they are guaranteed to be unique and stable.

With BMP Entity beans, the responsibility for generating these ID values will yours—the bean provider. Whether numbers and letters or just numbers are used is up to you, although just numbers are often used in an ascending sequence (that is, 1, 2, 3, and so on). If you adopt this strategy, you could calculate the values by calling a stateless Session bean—a number fountain, if you will. A home method could perhaps encapsulate the lookup of this NumberFountainBean.

The implementation of such a NumberFountainBean can take many forms. There will need to be some persistent record of the maximum allocated number in the series, so a method such as getNextNumber("MyBean") could return a value by performing an appropriate piece of SQL against a table held in an RDBMS:

begin tran

update number_fountain
set  max_value = max_value + 1
where bean_name = "MyBean"

select max_value
from  number_fountain
where bean_name = "MyBean"


One disadvantage with this approach is that the NumberFountainBean—or rather, the underlying database table—can become a bottleneck. A number of strategies have been developed to reduce this. One is to make the getNextNumber() method occur in a different transaction from the rest of the work. You will learn more about transactions on Day 8; for now, it is just necessary to know that while this will increase throughput, there is the risk of gaps occurring in the sequence.

If non-contiguous sequences are acceptable, even better throughput can be achieved by implementing a stateless Session bean that caches values in memory. Thus, rather than incrementing the maximum value by 1, it can increment by a larger number, perhaps by 100. Only every 100th call actually performs an SQL update, and the other 99 times, the number is allocated from memory. Of course, if the system crashes or power fails, there could quite a large gap.

A final enhancement that improves scalability further and also improves resilience is to arrange for there to be a number of beans, each with a range of values. For example, these might be allocated using a high-order byte/low-order bytes arrangement.


Countries that allocate car license plates by state or by district are effectively using this approach.

One advantage of implementing a Session bean, such as NumberFountainBean, is that it isolates the dependency on the persistent data store that is holding the maximum value. Also, the SQL to determine the next available number is easily ported across RDBMS. On the other hand, many organizations use only a single RDBMS, so such portability is not needed. In these cases, the RDBMS may have built-in support for allocating monotonically increasing numeric values, and this can be used directly. For example, SEQUENCEs can be used in Oracle, while both Microsoft SQL Server and Sybase provide so-called identity columns and the @@identity global variable. So, for BMP Entity beans, another way to obtain the next value is to perform the SQL INSERT, obtaining the value from the back-end RDBMS. Note that most of these tools have the same scalability issues as the home-grown NumberFountainBean, and most also provide optimizations that can result in gaps in the series.

There is an alternative to using numbers for ID values, namely to generate a value that must be unique. On Windows PCs, you may well have seen strings in the format


In case you are wondering, this was found by delving into the Windows Registry and (apparently) represents the FormatGUID for .AVI files (whatever that means!). The point is that it is—to all intents and purposes—guaranteed to be unique. In the case of GUIDs, it is unique because it is based on the MAC address of the ethernet card of the PC, plus the time.

Clearly, other algorithms can be created, and a quick search on the Web should throw up some commercial products and free software from which to select. For example, one algorithm generates values unique to the millisecond, the machine, the object creating the ID, and the top-most method of the call stack.

Granularity Revisited

A recurrent theme when developing Entity beans is in selecting an appropriate granularity for the bean. Prior to EJB 2.0, Entity beans could only provide a remote interface, which meant that a relatively coarse grained interface was required to minimize the client-to-bean network traffic. Indeed, this is still the recommendation made for Session beans in EJB 2.0 that have a remote interface.

With EJB 2.0, Entity beans can have a local interface, meaning that the cost of interaction with the client becomes minimal. If the cost of interaction of the Entity bean to the persistent data store is not too high, fine-grained Entity beans are quite possible. This may be true, either because the EJB container can make optimize the database access in some way (true only for CMP Entity beans) or if the data store resides on the same computer as the EJB container and, ideally, within the same JVM process space.


Running a persistent data store in the same process space as the EJB container is quite possible; a number of pure Java RDBMS—including Cloudscape, the database bundled with the J2EE RI—provide an "embedded mode."

Under BMP however, the advice is generally not to use fine-grained Entity beans, principally because the EJB container will be unable to perform any database access optimization. Choosing the granularity is then best determined by focusing on the identity and lifecycle on the candidate Entity beans. Hence, order and order-detail should be a single Order bean, but customer and order, while related, should be kept separate.

In the case study, you will find that the Job bean writes to both the Job table and also the JobSkill table (to record the skill(s) needed to perform the job).

Beware Those Finder Methods!

As you now have learned, Entity beans can be created, removed, and found through their home interface. While these all seem straightforward enough operations, there's danger lurking in the last of these; finder methods can be dangerous. Specifically, they can cripple the performance of your application if used incorrectly.

This probably doesn't seem obvious, but if you consider the interplay between the EJB container (implementing the local-home interface) and the bean itself, it becomes easier to see:

  • The local-home interface's findManyByXxx() method is called. For the purposes of this discussion, this finder method returns a Collection.

  • The local-home interface delegates to a pooled bean, calling its ejbFindManyByXxx() method. This performs an SQL SELECT statement (or the equivalent), and returns back a Collection of primary keys to the local-home interface.

  • The local-home interface instantiates a Collection the same size as was obtained from the bean and populates it with local proxies. Each local proxy is assigned a primary key.

So far so good, the client receives a Collection of proxies. Suppose now that the client iterates over this collection, calling some getter method getXxx().

  • The client calls getXxx() on the first proxy in its Collection. The proxy holds a primary key, but there is no corresponding bean actually associated with the proxy. Therefore, the EJB container activates a bean from the pool, calls its ejbLoad() lifecycle method, and then finally delegates the getXxx() business method. After that method has completed, the ejbStore() method is called.

  • This process continues for all of the proxies in the collection.

You can probably see the problem; the persistent data store will be hit numerous times. First, it will be hit as a result of the ejbFindManyByXxx() method; this will return a thin column of primary key values. Then, because ejbLoad() is called for each bean, the rest of the data for that row is returned. This is shown in Figure 6.8.

Figure 6.8 Finder methods can result in poor performance under BMP.

Consequently, if 20 primary keys were returned by the bean following the initial ejbFindManyByXxx(),the database will be hit in all 41 times—once for the initial SELECT and two times each for each of the beans.

There are a number of techniques that can eliminate this overhead, each with pros and cons:

  • The most obvious solution is to not use finder methods that return Collections of many beans. Instead, use stateless Session beans that perform a direct SQL SELECT query against the database, iterate over the ResultSet, and return back a Collection of serializable value objects that mirror the data contained in the actual entity. This technique is called the Fast-lane Reader.

  • Another technique that can be used is to alter the definition of the primary key class. As well as holding the key information that identifies the bean in the database, it also holds the rest of the bean's data as well. When the original finder bean returns the Collection of primary keys, the primary keys are held by the local proxies. When the beans are activated, they can obtain their state from the proxy by using entityContext.getLocalObject().getPrimaryKey(). This technique has been dubbed the fat key pattern, for obvious reasons.

  • Last, you may be able to remove the performance hit by porting the bean to use container managed persistence. Because under CMP the EJB container is responsible for all access to the persistent data store, many will obtain all the required information from the data store during the first findManyByXxx method call, and then eagerly instantiate beans using this information. You will be learning more about CMP tomorrow.

Incidentally, Figure 6.8 shows a graphic illustration of why Entity beans should, in general, define only a local interface—not a remote interface. If the client were remote rather than local, the total network calls for a finder method returning references to 20 beans would be double the original figure, namely 42! Moreover, every subsequent business method invocation (call to getYYY() for example) would inflict a further 20 network calls.

EJB Container Performance Tuning

Many organizations are wary of using Entity beans because of the performance costs that are associated with it. You have already seen the performance issues arising from using finder methods, but even ignoring this, any business method to an Entity bean will require two database calls—one resulting from the ejbLoad() that precedes the business method and one from the ejbStore() to save the bean's new state back to the data store.

Of course, these database calls may be unnecessary. If a bean hasn't been passivated since the last business call, the ejbLoad() need not do anything, provided that nothing has updated the data store through non-EJB mechanisms. Also, if the business method called did not change the state of the bean was, for example, a getter accessor method, the ejbStore() has nothing to do also.

Another scenario is where a bean is interacted with several times as part of a transaction. You will be learning more about transactions on Day 8, so for now, just appreciate that when a bean is modified through the course of a transaction, either all of its changes in state or none of them need to be persisted. In other words, there is only really the requirement to call ejbStore() once at the end of the transaction.

Taking these points together, the amount of network traffic from the EJB container to the persistent data store can be substantially reduced, down to the levels that might be expected in a hand-written J2SE client/server application. Although not part of the EJB specification, many EJB containers provide proprietary mechanisms to prevent unnecessary ejbLoad() or ejbStore() calls. Of course, the use of these mechanisms will make your bean harder to port to another EJB container, but you may well put up with the inconvenience for the performance gains realized. Indeed, if you are in the process of evaluating EJB containers, as many companies are, you may even have placed these features on your requirements list.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020