Hi Randy,
Yep - the idea is that we would want to have a "cluster" of containers
distributed across several machines so that we can cope with the possibly large
amount of hits.
As I mentioned in my previous email - we currently utilise a model2 (MVC)
architecture using servlets, jsp and "normal" javabeans.
We've also implemented a persistence layer that handles the CRUD methods for the
beans and optimistic locking,
Currently, since we don't really store any state (apart from sessions - which we
is ok since requests in the same session always go to the same server) in the
servers we don't have any synchronisation problems - ie we instantiate the beans
from the db at every request.
It would be nice for us not to have to instantiate the beans at every request -
which I believed EJB would enable us to do by holding in memory caches of beans.
However it now looks (as you have said in your <gemstone:vendor/> tag) that this
is a vendor specific add-on and hence a problem for us as we want our
applications to remain portable.
It seems that although EJB allows in memory caches - this is pretty useless when
you have more than one server since no synchronisation is performed between them
according to the EJB spec.
I'm interested in EJB but I've yet to be convinced that EJB *per se* can
actually add anything to our setup.
Its seems to me that EJB simply would add distributed transactions (which we
wouldn't use) and give us RMI interfaces to our business objects (which we
wouldn't need).
Is this is a fair summary of the capabilities of EJB or am I missing something
(and I guess I am ;-) ) ...
Randy Stafford wrote:
> Hi Tim,
>
> I'd like to explore your premise a bit more. What is your definition of an
> "ejb server"? (I'm assuming you mean an "instance" of an EJB container).
> Are you assuming that there is only JVM per ejb server, and that is why you
> need a "cluster", perhaps distributed across multiple machines, for
> scalability?
>
> <vendor>
> A GemStone "instance" can involve an arbitrary number of load-balanced VMs,
> spread across multiple machines if necessary. And GemStone can
> automatically maintain entity bean state consistency between and within
> these VMs (subject to transaction boundaries) by virtue of its unique
> Persistent Cache Architecture (PCA). Note that GemStone can also leverage
> PCA to maintain HttpSession state consistency between multiple servlet
> engine VMs.
> </vendor>
>
> Randy Stafford
> Senior Architect
> GemStone Professional Services
>
> > -----Original Message-----
> > From: Tim Fox [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, August 23, 2000 4:23 AM
> > To: [EMAIL PROTECTED]
> > Subject: Question on clustering and scalability
> >
> > I have a question on the maintaining of state consistency and
> > scalability on ejb servers.
> >
> > If I have, say, two ejb servers working in a load-balanced arrangements.
> >
> > Both servers are serving the same ejb classes.
> >
> > Client A is editing the Customer entity bean relating to "John Smith" on
> > server A.
> > The Customer entity bean relating to "John Smith" is also cached in
> > memory on server B after a previous update. (I am assuming ejb servers
> > cache objects in memory)
> >
> > Client A commits his changes to the underlying database.
> > How does ejb ensure that the in memory cached instance of "John Smith"
> > on server B is updated to reflect the changes made by Client A?
> > Does it fire off an "update" event to all the servers?
> > If so, and we have n servers then I image we have a scalability problem
> > of order n-1. (Ie the server has to notify every other server that the
> > update has happened)/
> >
> > If it doesn't then how can I possibly use entity beans in a load
> > balanced environment?
> >
> > TIA
> >
> > --
> > Tim Fox (��o)
> >
> > Hyperlink interactive
> > http://hyperlink.com
> > email: [EMAIL PROTECTED]
> > phone: +44 (0) 207 240 8121
> >
> > ==========================================================================
> > =
> > 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".
--
Tim Fox (��o)
Hyperlink interactive
http://hyperlink.com
email: [EMAIL PROTECTED]
phone: +44 (0) 207 240 8121
===========================================================================
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".
