Co-Location optimization for reusable EJB in WebLogic


EJB design: Co-Location optimization for reusable EJB in WebLogic

  1. Hello:

    Here is the situation:
    We have an EJB BeanA that is so useful we want to use it from eveywhere - from application1.ear, application2.ear, applicationN.ear.
    This is frequently used so we would like it to always be local call. In other words we would like to use CoLocation optimization that WebLogic 5.1 used to do so well - just use InitialContext() with no parameters :-)

    This presents a problem - in WLS 6.1 this will only happen if we are in the same classloader - right?
    So what are we to do - put a copy of the BeanA in each EAR file we want to use it from? What if we decide to change BeanA?

    Any suggestions?

  2. Gennadiy,

    I think this passage from WLS documentation explains everything:

    "Application Classloading and Pass by Value or Reference


    WebLogic Server includes an optimization to improve the performance of Remote Method Interface (RMI) calls within the server. Rather than using pass by value and the RMI subsystem's marshalling and unmarshalling facilities, the server makes a direct Java method call using pass by reference. This mechanism greatly improves performance and is also used for EJB 2.0 local interfaces.

    RMI call optimization and call by reference can only be used when the caller and callee are within the SAME application. As usual, this is related to classloaders. Since applications have their own classloader hierarchy, any application class has a definition in both classloaders and receives a ClassCastException error if you try to assign between applications. To work around this, WebLogic Server uses call by value between applications, even if they are within the same JVM.

    Note: Calls between applications are slower than calls within the same application. Deploy components together as an EAR file to enable fast RMI calls and use of the EJB 2.0 local interfaces."

    As you see, if you want to stick with local calls, the only way will be to package bean with each application (as you, actually, already do) and redeploy each application when the bean is changed.

    Hope it helps.