Continuing on with a look at common problems in EJB, it’s time to move to one area that is fairly well understood: the overhead of RMI traffic. More often than not, more time is spent waiting for networks to respond than on actual processing when dealing with EJB. So far, I have spent a lot of time talking about creating a new entity, such as the Forethought office. In that case, very little “back-and-forth” traffic occurs:
Object ref = context.lookup("java:comp/env/ejb/OfficeHome"); OfficeHome home = (OfficeHome) PortableRemoteObject.narrow(ref, OfficeHome.class); Office office = home.create("Dallas", "TX");
In this case, once the home interface of the bean is located, a single call creates the new office. However, when obtaining information about an office, more calls are needed:
String city = office.getCity( ); String state = office.getState( );
While these two calls look pretty harmless, each requires a round-trip RMI call. The remote stub has its method invoked, initiates a remote method invocation, waits for a response, and returns that response. All this depends on network latency and all the other costly issues that surround any network transmission. While even this doesn’t seem too bad, take a look at a slightly more complex object:
String sku = product.getSKU( ); String name = product.getName( ); String description = product.getDescription( ); float price = product.getPrice( ); // etc...
Here, multiple trips over the network are required for these ...