Chuck,
Answers:
> -----Original Message-----
> Does PCA provide fault tolerance over multiple machines transparently (to
> the servlets)?
>
Yes. PCA is transparently replicated across nodes in a cluster. Individual
nodes can fail while the cluster continues to execute.
> 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.
>
Entity Beans to memory is problematic becuase EB's are designec to be
transactional. Also you would have to arrange for distribution of that
memory yourself. GemStone/J's PCA solves both problems.
> Although the idea of eliminating the Entity Bean makes sense from a
> performance perspective.
>
When you have native persistence, EB's are kind of redundant. They only
introduce layers that add over head. Some folks like to use them anyway for
portability reasons though.
> 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.
>
With GemStone/J this Is built into the container, but is arguably
proprietary. Then again you can write you code in such as way as to be
portable in this area.
> 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".
===========================================================================
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".
