Nirvana(on behalf of vaheesan Selvarajah) wrote:

>but krishnan in your code once a ref to a home is obtained then it is kept
>in the hashtable and when another client invokes the same bean then the same
>ref which was held in the hashtable would be returned which stops the
>request to go to the next server in the cluster. right??? just like having
>
>
>lookup in JSP/Servlet init() methods.... hence no posibility for round
>robin...
>Am I right?
>
>r
>vahees
>

    It depends, mostly on what the client stubs are doing.  Some app
servers may have "smart" stubs which route each call to a different
clustered server.  With other app servers, once a stub is instanciated
it is tied to a single server instance.
    App servers that use an ORB (relying on IIOP) have the best of both
worlds IMHO.  ORBs resolve a remote reference (be it for a Home or
Remote interface) once when first used and then continue to use that
server's endpoint (tcp host/port) until there is a problem with
communications.  At that stage, two things can happen, depending on
whether the reference is persistent or transient (& how the ORB is
configured!).  For a persistent reference the ORB may capture the
communication failure and transparently attempt to locate an alternative
endpoint (in the cluster). If it suceeds the client code will never
know.  If it fails to locate another server the client will get a
RemoteException.   For transient references the client will get a
RemoteException immediately.  If you want to do round robin you have two
alternatives - get a new reference (either via JNDI for Homes or via
Home.[create|find] for the Remotes) every time you would like the
load-balancing to kick in.  Alternatively, you may be able to quickly
convert the reference into a handle and back into a reference again,
thus 'fooling' the ORB into thinking it has a new reference.  In the
case of the code you mention, yes, round-robin would not kick in (unless
the ORB is doing something *very* weird with method call counts)

In any case, as Krishnan said, this is all vendor specific - you should
check your vendor's docs to see how your app server supports load
balancing & fault tolerance.  I'd go one step further though and test
the behaviour of your app server to make sure it is in line with docs.
 High end features like clustering capabilites are subject to lots of
marketing spin since these features are the big diffrentiators...

j.

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to