hi David,
I believe without nick picking that it obvious the solution I was proposing
was for state that is common to all clients and which does not in fact
change. This cache could be loaded from a database and then accessed by the
stateful session beans. Now there is a possibility with many client
transactions that a container will create more stateless sesison beans with
the same copy of the data but I believe that this would be alot smaller than
having each client keep their own copy. With this the server will not come
to its knees. My reading from the post that this database rules engine was
not volatile data, the client data was. This is usually the case. Now if in
fact this data could change then we have other options like a corba server,
jndi entry (refresh by some managment console -> session bean), or a
stateless session (with the synchronization interface) bean that saves the
data to the database which is subsequently read on each business method
call.
William
PS: Maybe was description was not so clear because of my previous experience
building such rules systems along with assuming this this common knowledge.
> -----Original Message-----
> From: David Blevins [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, February 18, 2000 12:43 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching data in an stateful session EJB???
>
> This is an inaccurate portrayal of stateless session beans. Stateless
> session beans do not guarantee conversational state to anyone. This means
> you cannot mutate its values and expect them to be the same the next time
> you access a stateless session bean of that type. This does not mean that
> stateless session beans cannot hold information, but the information would
> be immutable and static in regards to it's state. The only way one can
> expect dynamic behavior from a stateless session bean is if the behavior
> is
> based on the parameters passed in or information outside of the stateless
> session bean. In both cases the true dynamic, conversational, or mutable
> state lies outside the bean; leaving the stateless session bean for all
> intense purposes, stateless.
>
> So getting back to the caching advice.
> You cannot cache data that was previously unknown in a stateless session
> bean. You may be able to hand dynamic data to a stateless session bean,
> but that bean will need to put it somewhere stateful or discard it. In
> this
> situation you would be relying on something outside EJB to cache your
> data,
> unless of course that bean calls another bean that is capable of
> maintaining
> conversational state.
>
> -David
>
> "> Please remember that a stateless session bean does not mean it cannot
> keep state,
> > its just that the state is not for on one client its for all of them.
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Louth, William (Exchange)
> > Sent: Thursday, February 17, 2000 3:09 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Caching data in an stateful session EJB???
> >
> >
> > hi jeff,
> >
> > I think the solution is a combination of the two. The stateless for the
> > database reference data and the stateful for the client values. Please
> > remember that a stateless session bean does not mean it cannot keep
> state,
> > its just that the state is not for on one client its for all of them. I
> > think if you moved to the 100% stateful solution proposed you
> > would probably
> > suffer memory problems or excessive io through passivation of the
> > same data
> > across clients. So determine what data relates only to the client
> > (stateful)
> > and what relates to them all (stateless session bean) and you
> > will porbably
> > meet your performance goals. One question ... how is the rule based
> engine
> > implemented (ejb, jni, corba.....) this could lead to some more options.
> >
> > William
> >
> > PS: Please remember that advice giving on this newgroup maybe sometimes
> > reflective of the failings of some vendors offering. The ejb
> > container that
> > I use does not seem to have problems scaling this is in part to my good
> > design and their superior implementation of ejb1.1 and corba 2.3.
> > good luck.
> >
> > > -----Original Message-----
> > > From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
> > > Sent: Wednesday, February 16, 2000 1:41 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Caching data in an stateful session EJB???
> > >
> > > Jeff Davidson wrote:
> > >
> > > > We are designing a system based on J2EE and EJB which needs to
> service
> > > thousands
> > > > of client applications. Originally we thought that each client
> would
> > > interact
> > > > with one stateful session EJB in order to collect & cache data
> pulled
> > > from
> > > > corporate databases. However, ass I've been reading more on EJBs,
> it
> > > sounds
> > > > like this may not be a very good approach in terms of scaling and
> > > > performance. If we use stateless session beans, where can we
> > cache the
> > > > data retrieved from the database? We need the data for subsequent
> > > > calls to a rules-based engine to have it process and return
> > information
> > > > which we then return to the client app. Then, as we collect
> > information
> > > > from the client app, we need to combine this with the data from the
> > > > db to be able to make more requests to the rules-based engine. So
> we
> > > need
> > > > to cache it somewhere, but where?
> > >
> > > Perhaps you should question your own assumptions about the performance
> > > penalties of
> > > using Stateful Session beans, because the scenario you just described
> > > indicates that
> > > a stateful session bean is what you need. Why reinvent a cache
> > per client
> > > -- which
> > > is what you need -- when stateful session beans provide that already.
> > >
> > > -Richard
> > > --
> > > Author of Enterprise JavaBeans
> > > Published by O'Reilly & Associates
> > >
> > > EJB FAQ
> > > http://www.jguru.com/faq/EJB
> > >
> > > EJBNow.com
> > > http://www.ejbnow.com
> > >
> > >
> >
> ==========================================================================
> > > =
> > > 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".
> >
> >
>
> ==========================================================================
> =
> 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".
