Senthoor,
Load balancing is again vendor specific. With some
products you need to do something extra - like creating
cluster aware stubs.
With our product (built on top of VisiBroker - a high
performant, scalable Corba implementation), clustering
is built into the architecture. So clustering is almost
easy as plugging in another server and load balancing
and failovers are immediately available. (our server
side and client side stubs are already 'smart')
You do raise an interesting point - which is load balancing
(btw that source code was used in a clustered environment).
Normally you would want a single client to talk to a server
and remain connected to that server for performance reasons.
If a single client had to alternate between a cluster of servers
for every method call, then performance would drop - simply
because of the cost of looking up and setting up a connection
to different servers. Of course multiple clients would round
robin (or some similar load balancing algorithm - but we use
round robin as a default) between servers. But to put a long
story short, yes - clustering is a vendor dependent feature
and you need to be aware of how the vendor implements it.
See http://archives.java.sun.com/cgi-bin/wa?A2=ind0106&L=ejb-interest&P=R2508
for some more new terms and concepts :)
-krish
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Senthoorkumaran
> Sent: Thursday, September 13, 2001 8:07 AM
> To: [EMAIL PROTECTED]
> Subject: Re: IntialContext
>
>
> I reffered to the link you have specified below. Don't you think that
> methodology will be a draw back when it comes to load balancing? Just wanted
> clarify :-)
>
> Senthoor
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Krishnan Subramanian
> Sent: Wednesday, September 12, 2001 8:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: IntialContext
>
>
> Avi,
>
> They would be - if an instance of X "used" an
> instance of Y i.e. if you called
> instanceOfY.anotherMethod() from within your
> session bean X's someMethod, then both
> c1 and c2 will lookup the same definitions
> under "java:comp/env" defined in X's descriptor.
>
> In other words - for a particular process
> (or VM), an initial context instance is
> [re]usable by all beans (and normal java objects
> in turn referenced by those beans).
>
> You are right that a "java:comp/env" namespace
> is 'private' to that bean - and not available
> to other beans and I am not trying to debate that
> point. See above for debatable point ;)
>
> The point is moot if subsequent initializing of
> the context is optimized by the vendor (lightweight).
> Else, you might see performance improvements by caching
> that one instance within the VM.
>
> http://archives.java.sun.com/cgi-bin/wa?A2=ind0105&L=ejb-interest&P=R19960
>
> -krish
>
> >
> > I think what the original poster asked is, given the following code
> sequence
> >
> > public class X implements SessionBean {
> >
> > public void someMethod() {
> > Context c1 = new InitialContext();
> > }
> >
> > // ...
> >
> > }
> >
> > public class Y {
> >
> > public void anotherMethod() {
> > Context c2 = new InitialContext();
> > }
> >
> > }
> >
> > are c1 and c2 logically identical? This is a vendor-independent question,
> > and the vendor-independent answer is no, c1 is not equivalent to c2,
> because
> > of the java:comp/env namespace. This has nothing to do with vendor
> > optimizations AFAICT.
> >
> > - Avi
>
> ===========================================================================
> 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".
>
> ===========================================================================
> 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".
>
>
===========================================================================
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".
