I take it this is an EJB2 bean? EJB2 directly stores the client proxy in JNDI, so yeah I
can see how all in-VM clients would end up with a shared reference to a single
LoadBalancePolicy instance. EJB3 should work somewhat differently, as what's stored in
JNDI is a javax.naming.Reference which results in an ObjectFactory instantiating a new
LoadBalancePolicy instance each time the client does the JNDI lookup.
TBH, w/ EJB2 I think you are better off w/ your serialization/deserialization hack, as
it's extremely unlikely the EJB2 impl will be changed. It would take a pretty
significant change to fix this (basically changing to the EJB3 approach) and EJB2 is in
maintenance mode.
Another problem you'll face is the EJB proxy includes logic to detect when the bean
container is present locally, in VM. If it is, the call is routed to the local bean; it
won't be load balanced. See "Why are calls between clustered session beans not
load balanced even though load balancing policy is Round Robin?" on
http://www.jboss.org/community/docs/DOC-9306.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269433#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...