Deactivating Weblogic Load Balancing Optimization for collocated objects

Question

Is there a way to deactivate the optimization for collocated objects that Weblogic uses by default for a specific EJB ?

EDIT: Some context :

We have a scheduler service that runs inside one node of the cluster. This is for historic reasons and cannot be changed at the moment.

This service makes call to an EJB and we would like to load balance these calls. Unfortunately at the moment every calls runs on the node that hosts the scheduler service because of the optimization mentioned in the question.

I was thinking of coding a custom load balancing class however this optimization seems to be done before the load balancing step happens.

Answer 1

There don't seem to be too many J2EE guys out here. you might want to try the BEA/ORACLE forums or the SUN forum

Answer 2

Not being too familiar with guts of weblogic but reading their material I would say you cannot, without some amount of trickery.

It does seem though that you can put a JMS (MDB) facade in front of your EJB that does not abide by the collocated object optimization.

OR

If your scheduler is servlet based, you should be able to deploy it in a separate web-application within the container and have it execute calls to the EJB cluster.

Answer 3

How many nodes are there in your cluster? Have you considered deploying the EJB to nodes other than the one the scheduler service has been deployed to?

Answer 4

Supposing you are trying to call a remote EJB (load balancing on local ejbs can only be obtained through an indirection trick like Patrick mentioned) you will have to create a new InitialContext using the address of the cluster instead of a particular server. This new IC will provide stubs as if you were a foreign client, subject to the same load balancing strategies as they are.

Unfortunately, this means that EJB3 injections won't work. You will have to do the lookup yourself. There is a chance, an this is pure speculation, that those stubs you can get from the cluster IC are serializable. In other words, it might be possible to bind them and get them injected using @Resource afterwards.

Answer 5

Hi

We are also in similar situation where request goes to one node of a cluster and then the subsequent request from here should go other node of a cluster.

Michel or anyone has the solution for this, please share.