Does PCA provide fault tolerance over multiple machines transparently (to
the servlets)?
We were looking at using an Entity Bean to store info to an in memory object
(where we would provide the replication) or to an OODBMS.
Although the idea of eliminating the Entity Bean makes sense from a
performance perspective.
It seems to me that this is a significant hole in the EJB specification.
Shouldn't there be a third type of bean (a "control" bean??) to handle
multiple concurrent client access in memory AND provide scalability and
fault tolerance. It seems like a common scenario to need have one logical
component "instance" provided as many synchronized, distributed "physical"
component instances without the need to explicitly store the data to a
database to provide the synchronization. It would be nice to not have to
look outside of the EJB container (i.e to PCA or other OODMSes) to get this
functionality.
Anyone else have this issue/agree/disagree?? Any comment from anyone from
Sun on this issue?
Thanks,
Chuck
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Randy Stafford
Sent: Thursday, April 20, 2000 3:44 PM
To: [EMAIL PROTECTED]
Subject: Re: Bean Design Question
It's the "remaining synchronized" requirement that is challenging.
Conceptually, you only want one "instance" of the chat text, right? Seems
to me your only choices are sharing the data via DBMS, or using some form of
socket connections between the different instances of the component running
on separate machines (or between them and some mediator, to avoid the
n-squared problem). With GemStone you could have the "component" be a
servlet, and have multiple servlet engine VMs (if necessary) on the same
machine (or an array of them, if necessary), and give each component
instance / servlet VM direct access to the same chat text instance cached in
GemStone's Persistent Cache Architecture (OODBMS). This approach would
leave EJB (and associated object distribution overhead) out of the picture,
and PCA's shared-memory architecture would facilitate fast access to the
shared data by each servlet engine VM.
Best Regards,
Randy Stafford
Senior Architect
GemStone Professional Services
> -----Original Message-----
> From: Chuck Butkus [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, April 20, 2000 1:23 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Bean Design Question
>
> I guess I should be a little more specific.
>
> One of the components will handle chat text between multiple endpoints.
> The
> component needs to keep the text sent from each endpoint so at the end, if
> requested, it can store it to a database.
>
> We don't want each message as it is received to be stored to a database as
> that would kill performance, yet we want the chat component to be scalable
> (i.e. instances of the same component running on separate machines but
> remaining synchronized so clients can use different instances) and fault
> tolerant (i.e. if one of the servers goes down, the client is rerouted
> without even knowing anything has happened).
>
> Can this be accomplished via a stateless session bean? Where would the
> chat
> text be stored and how can it be replicated across multiple servers for
> failover purposes?
>
> Thanks for the help,
> Chuck (a Java/EJB newcomer crossing over from the C++/DCOM world)
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Randy Stafford
> Sent: Thursday, April 20, 2000 2:40 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Bean Design Question
>
>
> Chuck-
>
> Sounds like a perfect fit for a stateless session bean.
>
> Best Regards,
> Randy Stafford
> Senior Achitect
> GemStone Professional Services
>
> > -----Original Message-----
> > From: Chuck Butkus [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, April 20, 2000 11:21 AM
> > To: [EMAIL PROTECTED]
> > Subject: Bean Design Question
> >
> > In our application, we have the need for a component that can be
> accessed
> > by
> > multiple clients but that does not need to store its information
> > persistently. It needs to have high performance so storing and loading
> > to/from persistent storage on a regular basis would not work.
> >
> > We are looking at using EJB to provide scalability and failover so we
> > would
> > like to have this object represented as an Enterprise Bean.
> >
> > The problem is it doesn't seem to fit in either the Session or Entity
> bean
> > category.
> >
> > Can we use an entity bean that doesn't talk to a database in its
> > ejbLoad/ejbStore methods?? How would this affect scalability and
> > failover?
> > Should this be an enterprise bean at all?
> >
> >
> ==========================================================================
> > =
> > 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".
===========================================================================
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".
