Randy Stafford wrote:
>
> 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.
>
The container has all the control it needs to 'replicate' a single EJB
instance across any number of JVM's and machines. Of course, this is a
challenging thing for a container vendor to optimize so there will
likely be containers that don't optimize this case.
> > > 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".
===========================================================================
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".
