Session Façade
To test this design pattern we searched JazzCat catalog for albums containing a particular song title or a substring of it. This was an interesting case, as we had to call a few entities to provide this listing: Album (the item we are searching for), Take (holds the song title), Track (identifies occurrences of Takes on Albums), and Musician (identifies the artist name for an Album).

This is straightforward with EJB 2.1. The dispatcher servlet of the test harness calls the FacadeOn servlet, which in turn calls the stateless session bean that acts as the façade and calls all the necessary entities to obtain the required information. This is later sent back to the FacadeOn servlet in the form of a Data Transfer Hash Map and presented to the user.

EJB 3.0 works pretty much the same until you get to the point of calling the entity beans. Instead, we call the Entity Manager and, using named queries, we load the information from the POJOs into the Data Transfer Hash Map. The main difference is that with EJB 2.1, we look up the entity beans using ejb-local-refs and then work on these entity beans to get the required information.

We conducted these tests with 15, 25, 50, 75, and 100 simultaneous users. The test script did 10 different searches starting with the letter a to the letter j. To our surprise, we found that EJB 3.0 had roughly double the performance of EJB 2.1. Let's look at the response time in Figure 2. We can see that as the load increases, the difference in response time increases dramatically, from 18% for 15 users all the way up to 58% for 100 users, giving an overall average of 46%.

Even more interesting is the TTR chart in Figure 3, which clearly shows the throughput for EJB 2.1 Session Façade more or less stable for all user loads, but decreasing very slowly at 25 users. In the case of EJB 3.0, it peaks at 50 users and then begins a slow descent. However, the average throughput of EJB 3.0 is roughly double that of EJB 2.1.

Just to provide some numbers, with 100 users the AART of EJB 3.0 is 716 milliseconds and the throughput is 140 requests per second. The wonderful performance of EJB 3.0 for such a popular design pattern is a welcome surprise, which only makes us want to use EJB 3.0 even more.

Container-Managed Relationships
Although entity beans in general and CMR in particular have a bad reputation, various EJB containers actually have high-performance implementations. Because of this, we expected the performance comparison would be basically the same.

This test case is based on a search that exercises the relationships between the tables of the JazzCat application. Given a song title, or a substring of it, to search for, the test servlet displays a list of takes matching the title, along with the band members playing on each particular take of that title. Among the many relationships and navigations that exist in this application and this search, a couple are worth highlighting: there's a one-to-many relationship between Takes and Bands (a Take has many Band members), and a many-to-one relationship between Bands and Musicians (several different Bands can have the same Musician as a member).

Compared to programming this search using Bean Managed Persistence Entity Beans, using Container Managed Persistence is really easy. However, we still have to deal with the Deployment Descriptor, where we have to declare all the relationships of each entity.

In contrast, using the annotations of EJB 3.0, we can quickly and easily define the relationships, such as the one between Takes and Bands:

@OneToMany(targetEntity="org.migrate.entity.Bands")
@JoinColumn(name="BANDS.TAKE_ID", referencedColumnName="TAKES.ID")
public List<Bands> getBandsList()
{
   return bandsList;
}

The EJB 3.0 test code is very similar to that of EJB 2.1 up to the point where the session façade bean calls the entity manager. Using the entity manager, we navigate through the POJO relationships using getter methods and we assemble the information for the test servlet to present to the user.

The test scripts for this test case were basically the same as those used for the Session Façade test case: 10 searches starting with the letter "a" up to the letter "j". We began with five users and then increased to 15, 25, 50, 75, and 100 users. (We had to add the case of five users because the throughput of EJB 2.1 peaked at 15 users.)

The results again were pleasantly surprising: the performance of EJB 3.0 was roughly double that of EJB 2.1. The chart for the response time looks very similar to that of the Session Façade test case - the difference starts with 20% for five users and pretty much jumps to 55% for the rest of the user load.

The results from the TTR standpoint can be seen in Figure 4. Here, the throughput of EJB 3.0 starts with a 25% difference and quickly grows to 140% to present an overall average of 111% better throughput.

If you're interested in running your own test cases using JazzCat application, the test harness, and the methodology we used, you can download a package that contains everything you need from www.jroller.com/resources/r/raghukodali/jazzcat.jar.

Conclusion
Considering that we used only a developer's preview of EJB 3.0, we're very impressed with this specification - at least Oracle's implementation of it. As mentioned earlier, we're very attracted to the simplicity and power of EJB 3.0. The wonderful work done with annotations and the persistence, the ability to use POJOs, and the ability to test outside of the container are very attractive all by themselves. But now, with an implementation that equals or doubles the performance of EJB 2.1 (at least for our test cases), we can't wait for the final specification and formal release of EJB 3.0.

Acknowledgement
Thanks to Phil Aston for his contributions with The Grinder 3.