Chris Raber wrote:
> 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.
>
[Randy Stafford] Another related point is that the instance of the
entity bean implementation class is necessarily in some VM. So if you only
want one conceptual "instance" of the chat text, you'd have to somehow make
sure all clients (servlets) always accessed the same EJB server VM - which
kind of defeats the purpose of load-balancing across EJB server VMs - or,
you'd have to find a way to replicate the EB state between VMs (without
using a DBMS, if you still don;t want to do that). An EJB-less solution may
be best for you.
> > 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".
===========================================================================
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".
