Recently I did an audit on a WebLogic 11g platform of one of our customers. There were many problems with the availability of their JAVA Applications. Some of the problems we’re platform related ( installation, configuration and infrastructure related) but a lot of them already existed in an earlier stage at application programming and configuration level.
So I decided to bundle some tips for JAVA programmers how they should configure their EJB, MDB and Servlet applications when they will be deployed on a WebLogic cluster.
This is an example of a typical EJB application architecture in WebLogic Server:
Some hints and tips:
- Use stateless session beans, when you don’t have heavy transactional load
- Make use of home-is-clusterable in weblogic-ejb-jar.xml  and set in on “true”. The EJB can be deployed to multiple managed servers in a cluster. Calls to the home stub are load-balanced between the servers on which its deployed, and if a server hosting the bean is unreachable, the call automatically fails over.
- On bean level, set stateless-bean-methods-are-idempotent in weblogic-ejb-jar.xml on “true”.
- Set stateless-bean-is-clusterable in weblogic-ejb-jar.xml on “true” to deploy EJB’s in a WLS cluster
- Use the stateless-bean-load-algorithm in weblogic-ejb-jar.xml for load balancing between EJB replica’s.
- With in EJB MDB listeners set  setting start-mdbs-with-application to false in weblogic-ejb-jar.xml or weblogic-application.xml with clustered EJB’s. This avoids  hanging of current  messages and processing of the MDB  listeners. Listeners will wait with processing messaging after other services are fully started in WebLogic ( JDBC, JCA, JMS)
- Configure in-memory replication of stateful session beans
- Use batching with Message-Driven Beans.You can enable MDB transaction batching by defining the max-messages-in-transaction element in weblogic-ejb-jar.xml deployment descriptor. Beware , database deadlocks can occur in an application where an MDB makes multiple calls to a database so not all MDB’s are suitable
- Use Multitier Clustered Architecture ( WebTier and Objectier separated) to utilize method calls of clustered EJB’s.
Single combined-tier clusters provide no opportunity for load balancing method calls to clustered EJBs. Because they  are deployed on all WebLogic Server instances in the cluster, each object instance is available locally to each server. WebLogic Server optimizes method calls to clustered EJBs by always selecting the local object instance, rather than distributing it to remote objects which causes more network overhead.This  is, in most cases, more efficient than load balancing each method request to a different server. But if the processing load to individual servers becomes unbalanced, it may eventually become more efficient to submit method calls to remote objects than process methods locally.To utilize load balancing for method calls to clustered EJBs, it’s better to split the presentation and object tiers of the application in separate physical clusters.
Failover EJB’s in a cluster
As stateless session EJBs do not maintain any server-side state, the EJBObject stub returned by the EJB home object can route a method call to any server hosting the object. Failover occurs only on idempotent methods.
Stateless session EJBs can have both a cluster-aware home stub and a replica-aware EJBObject stub. By default, WebLogic Server provides failover services for EJB method calls, but only if a failure occurs between method calls. For example, failover is automatically supported if there is a failure after a method completes, or if the method fails to connect to a server. When failures occur while an EJB method is in progress, WebLogic Server does not automatically failover from one server to another.
This ensures that database updates within an EJB method are not “duplicated” in a failover scenario. If a client calls a method which increments a value in a datastore and WebLogic Server fails over to another server before the method completes, the datastore would be updated twice for the client’s single method call. So, set the stateless-bean-methods-are-idempotent to “true” in weblogic-ejb-jar.xml, WebLogic  assumes that the method is idempotent and will provide failover services for the EJB method, even if a failure occurs during a method call.
Stateful session EJBs
Stateful session EJBs should be set to home-is-clusterable to “true.” This provides failover and load balancing for stateful EJB lookups. Stateful session EJBs can’t utilize replica-aware EJBObject stubs, and WebLogic Server does not provide failover services for method calls to stateful session EJBs.
Entity EJBs
WebLogic supports load balancing and failover only at the home level, and not at the method call level (the EJBObject level). Also Enitity EJBs should be set with the home-is-clusterable to “true.”
Edwin
These are best practices for programmers of course. I think programmers should be aware and think about were their applications will land on. Also the more applications get a ” production status”, the less knowledge is available from the people ( in this case administrators ). . Of course, applications maybe could work perfectly, but from my experience I see too many times that there wasn’t thought about were and how the apps  are running when they are live, like on what infrastructure, cluster architecture, network architecture. But  It is of course a 2 way track , environment should be configured properly. I forgot to mention but this is about applications on a 10.3.2 platform, not the most stable release of WLS.
Thanks,
I am using a lot of Stateless EJB session bean and have never these problems on a wls cluster. on wls 10.3.4 it works perfectly and the cluster aware stubs are also working fine.
we did a lot of crash tests ( kill -9 and server migrations ) under a heavy load but never lost any transaction.
Maybe these values are now default values.
by the way make sure that they never use Object as datatype on session bean facade cause this is not serializable