Hi Chuck,
I need some further information regarding what this component does from the
client perspective before I could pitch a solution. Are you building some
kind of chat-like solution where clients need to see the posts from the
other end pionts. Does the client only keep the text for the sake of
possible storage or because it needs to so that clients can poll from
unread messages? Is this something like a topic? Please elaborate.
kind regards,
William Louth
> -----Original Message-----
> From: Chuck Butkus [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, April 20, 2000 8: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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
