We have just done some performance tests with regard to calling an entity bean from either a java class or a session bean. The results show that calling from a session bean is 3 times faster than calling from a Java class. Has anybody seen these sorts of results before?

I expected it too be faster but not that much faster.

Thanks

Paul Clements

Your description did not mention the kind of setup that you have .. are your session beans in the same container as the entity bean ? Is the Java class that you mentioned calling the entity bean from within the container (e.g a delegate object within a session bean) or is it from a remote JVM ?

Session beans calling entity beans within the same container usually do not incur a remote method call (this is application server implementation dependant , though , but usually no remote method call is incurred)

Calling entity beans from a Java class, assuming the Java class is running on a remote JVM , incurs a remote method call , which is more expensive.

"Session beans calling entity beans within the same container usually do not incur a remote method call (this is application server implementation dependant , though , but usually no remote method call is incurred)"

In fact, the call is a local one when session bean invokes methods on the local interface of the entity and a remote one when invokes methods on remote interface. I don't think it depends on the application server at all, but it is in EJB specifiaction.

test

"In fact, the call is a local one when session bean invokes methods on the local interface of the entity and a remote one when invokes methods on remote interface. I don't think it depends on the application server at all, but it is in EJB specification."

Cristian ,
For pre EJB 2.0 , there was no concept of Local interfaces. Hence , the optimization from remote call -> local call for EJBs was indeed application server dependant. The optimization requirement was not in the pre EJB 2.0 specs either.

I'm not sure if EJB 2.0/2.1 specs mandates that EJBs within the same JVM to optimize to a local call. It is quite unlikely. From what I understand , it is only required that *if* Local interfaces are used , then the call must be a local call. The reason local interface was introduced , as explained by David , was to formalize the non-standard enhancement made by app server vendors. Since there is already a standard in the spec 2.0/2.1 for doing so , I see no reason why the "informal" remote to local call optimization should be redundantly made part of the specification.

This is correct. The "optimzation" has never been part of the spec. I strongly recommend making the choice between local and remote calling explicit. Otherwise interfaces that are coded to use call by value (RMI) can encounter subtle bugs with call by reference (local invocation). Also, if we use remote interfaces but rely on the performance of local calling, we have to catch redundant RemoteExceptions. In my view, writing code to catch exceptions that can never happen reflects a design error.

Rod Johnson
Expert One-On-One J2EE Design and Development

The application server is JBoss 2.4.4.

The Java class is not called from within a Session Bean but is on the same machine as the App server, hence different JVMs.

The session bean to entity bean is on the same container.

Hope that clarifies

Paul, does your session bean call methods on the local interface(s) of your entity, or on remote interface(s)?

Calls on the remote interfaces but we have done some tests with local interfaces and its pretty much the same performance as the remote one as they are both living in the same container.

Hi,

Most containers will optimise the Remote Calls within the same VM so that they are the same as a local call. I do not know JBoss but Weblogic has done this enhancement at least since 5.1. Local Interfaces have just made this enhancement more formal.

As a side note this enhancement does break the spec as now your remote call has local call behavour and will pass its parameters by reference.

David

This is exactly the performance difference I would expect, and one reason it's poor practice to give entity beans remote interfaces. The Session Facade pattern hides entity beans behind session beans. In EJB 2.0 we can enforce this by giving entity beans only local interfaces. This means, for example, that if a single session bean method invokes 3 entity bean methods, these calls will all by optimized within the EJB container, avoiding "chatty" remote calling.

Other benefits of the Session Facade pattern include decoupling client-side code from entity beans. For example, if entity beans give inadequate performance (as they often do) you can then change the implementation of youir session beans to use JDO, JDBC, TopLink or another persistence strategy without affecting clients.

Rod Johnson, author of Expert One-On-One J2EE Design and Development, which discusses this in detail.

Agree totally with your remarks exactly the solution I am proposing to my client who has an application which is exhibiting poor performance due partly I believe to the java->entity beans I have described. Just surprised about the performance hit but now confident of our results

BTW when will your book be available from the UK?

Paul, several people have asked me this. The book is shipping in the US and was printed several weeks ago, so I'm surprised that Amazon.co.uk is showing such a long lead time. I would have expected it to be in stores now. However, I will speak to Wrox Press and see if there's anything we can do to speed things up. The sample chapter on the Wrox site may contain some useful information, in the meantime.

There are three chapters dealing with data access and entity beans. I'm quite critical of entity beans in general, although there are some applications where they're appropriate. While most books present entity beans as a valuable and central part of J2EE, I don't think this this reflects real-world experience. I've come across many projects where entity beans have produced poor performance, even if optimized.

I think the introduction of local interfaces in EJB 2.0, while it makes entity beans more usable, tends to throw the whole entity bean concept into question. If objects don't need remote interfaces, why do they need to be modeled as EJBs? JDOs are much less heavyweight.

Hi,

Another couple of things Session facades give you,

(i) A transactional wrapper around your Entity beans. If you have mulutple Entity Beans that you want to take part in a transaction then a Session Facade allows you to do this.

(ii) Access to Container Managed Relationships. CMRs are not available from Remote Interfaces in EJB2.0 and CMR collections need to be accessed from within the transaction they are created.

David