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".
