Yabbut, he didn't want to share the data through an RDBMS because he was
concerned about performance - not to mention the overhead of distributed
object middleware...
RPS
> -----Original Message-----
> From: MARK HAPNER [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, April 21, 2000 8:16 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Bean Design Question
>
> Chuck Butkus wrote:
> >
> > 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.
>
> It is the job of the EJB container and resource managers to provide the
> plumbing needed to effectively implement sharing and fault resilence of
> entity state. The degree to which they do this is optional - some will
> provide sophisticated object caching and high availability features and
> others will provide none.
>
> The EJB Entity Model provides the leverage to do this by either giving
> the container direct control of the state (CMP) or by giving a DB
> control of the state (BMP).
>
> One of the fundamental goals of EJB is to eliminate the need for
> developers to write this kind of code themselves.
>
> An effective way to write a service that provides shared access to
> cached data is to write it as a normal CMP entity and run it on a
> container that provides the level of caching and fail-over that's
> needed. All entities and their containers can also leverage the caching
> and fail-over facilities provided by DB vendors.
>
> >
> > Anyone else have this issue/agree/disagree?? Any comment from anyone
> from
> > Sun on this issue?
> >
> > Thanks,
> > Chuck
> >
>
> ==========================================================================
> =
> 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".
