First off, I Don't work for Gemstone, but I really think you should
read the whitepapers on extreme clustering available at
http://www.gemstone.com
You'll see that clustering (and load balancing and high availability and
failover) can ALL be achieved TRANSPARENTLY simply because of their
architecture
based on multiple managed server VMs accessing shared memory which is
replicated
to multiple machines (overly simplified, but this is what it boils down to).
It's all in the architecture and given the elegance of this approach (and
the success
we've had with it) I simply don't see what all the fuss is about with
regards to
clustering. We simply never had to worry about it because the application
server
is properly architected and takes care of all the scalability issues.
I would like to read that paper by Waldo et al. Perhaps I'm missing
something and it
can set me straight... Is it available online somewhere?
Frank Sauer
The technical Resource Connection
a wholly owned subsidiary of Perot Systems
Tampa, FL
http://www.trcinc.com
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Cedric Beust
> Sent: Thursday, July 20, 2000 3:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Clustering: detailed comparison and survey
>
>
> I'm addressing the point Rickard skipped :
>
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of dan benanav
>
> > 3) I am unclear about stateful beans using weblogic clustering.
>
> <vendor>
>
> Stateful session beans are now replicated (in-memory) in Weblogic. The
> implementation is available in our current EJB 2.0 beta and
> will be included
> in our next release.
>
> </vendor>
>
> > The bottom line is that when you design your system for weblogic you
> > should be thinking about clustering up front.
>
> On a more general note, there is only so far that
> transparency will take you.
> The "Note on distributing computing" by Waldo et al. paper
> clearly explains
> why sometimes, transparency is not good for you (or simply cannot be
> achieved). There are things that you need to be aware of when
> you are making a
> remote call, and the same reasoning should be applied to a clustered
> application.
>
> Granted, the application server can alleviate a lot of this
> burden with
> techniques such as smart stubs, but that's just plumbing
> detail and it only
> represents a part of the picture. You are working at a higher
> level and
> ultimately, your design has to take clustering into account.
>
> > I would like to see a discussion and comparison of how
> other ejb servers
> > handle clustering.
>
> Looking forward to it.
>
> --
> Cedric
>
> ==============================================================
> =============
> 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".
