My post was in regard to a common point of confusion concerning the
difference between stateful and stateless session beans and not an attempt
to invalidate your proposed solution.
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Louth, William (Exchange)
> Sent: Monday, February 21, 2000 4:46 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching data in an stateful session EJB???
>
>
> 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".
>
>
===========================================================================
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".
