EJAPP Top 10 countdown: #8 - Incorrect usage of Java EE

Vincent Partington

Continuing the EJAPP Top 10 countdown, it's time to talk about number 8.

Apart from leading to badly architected applications, incorrect usage of Java EE can also cause your application to perform poorly. This problem is particularly prevalent in older applications that were developed before the POJO/lightweight revolution a few years back.

Lightweight frameworks like Spring allow the developer to pick and choose the infrastructure services (transactions, security, distributed objects) that are needed. Java EE (or J2EE as we used to call it) offers all of them all of the time. Application servers are tuned to not spend a lot of CPU cycles on the infrastructure services that are not used, but some developers succumb to the temptation to use these features when they are not needed. Not helping all this are the "best practices" that came into being with the first J2EE versions, e.g. Sun's J2EE patterns.

Some of the ways in which Java EE is used incorrectly are:

  • Using remote EJB's when local EJB's would suffice. Since EJB 2.0 it is possible to give an EJB a local interface thereby introducing call by reference. Most application servers (BEA Welogic 9.2, IBM WebSphere 6, and Oracle OC4J) can be configured to also use call by reference for remote objects. This improves performance but changes the method invocation semantics.
  • Using the Session Facade pattern incorrectly. This pattern was introduced to circumvent the latency of remote method calls. If improperly implemented (e.g. by having exactly one session facade to access all EJB's), this session bean becomes a bottle neck when the number of sessions beans is limited.
  • The EJB n+1 problem. When following relations, EJB before 2.0 suffered from the problem that to load a table n+1 queries were used: 1 to get the IDs for the objects to be loaded, and then another query for each of those objects to load the data. Of course, this has a huge negative impact on the performance of your application!
  • Home grown frameworks. Because Java EE, and especially the older version, offered such a poor programming model, a lot of home grown frameworks have been written. Although these form a central part of the application, not all of them are tested for performance.

There are two remedies to this problem:

Comments (4)

  1. Vladimir - Reply

    May 1, 2007 at 7:39 pm

    I think local interfaces are useless unless you use EJB Entity Beans. But, who does still use them? I think you should not call ejbs from ejbs INSIDE the same container, use POJOs instead. So, my humble conclusion is that the use of local EJB should not be used. Am I right? wrong?

  2. Vincent Partington - Reply

    May 2, 2007 at 7:51 pm

    I agree that EJB is not an optimal technology to start with. But if you are determined to use EJBs, you could at least use local EJBs to lessen the impact. Local EJBs can also be a relatively quick fix for badly performing applications using EJBs.

  3. Xebia Blog - Reply

    May 23, 2007 at 11:01 am

    [...] Number 8 - Incorrect usage of Java EE More information about number 8 can be found here. [...]

Add a Comment