A stateless session does not have any state (duh!) which makes it pretty
useless to handling any state at all (duh!) (such as a ro-data-cache).
A session is not shared between clients which makes it pretty useless since
the point of a cache is to optimize as many requests for data as possible.
The entity seems to be the only way to implement caches in EJB (since they
are shared by clients), but unfortunately they cannot be used either (at
least not in portable manner). The entities state is for most containers I
have tried flushed and read from the underlying datasource for each
transaction. I guess some containers could implement some kind of
intra-transaction cache of entities, but I haven't seen in the containers I
have tried.
Currently there are two alternatives, either model it as a non-EJB
CORBA-service or use the database data-cache.
The database-vendors have some decades of experience in handling data so I
guess they are the best bet to go for.
I guess they could be implemented as a Connector in the EJB
2.0-architecture, but that's only to my understanding of the whole.
Plumbing work such as caching of data is not what the EJB-specification is
about. It is about programming pure business-logic without having to deal
with things like these. It's the container-provider who should worry about
these things.
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Fontenot
> Sent: Monday, January 17, 2000 7:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching of read-only DB contents in an EJB
>
>
> Stateless Sessions beans sound like a good idea. How about
> creating a read
> only Cache as a static Singleton. When your EJB clients want to
> lookup data
> stored in the cache they could call a Stateless Session bean with
> the key as
> a method parameter. The static Singleton cache should not be subject to
> timeouts.
>
> I'm thinking:
> 1. Start EJB server
> 2. Start webserver/servlet engine
> 2a. An EJB startup servlet calls the EJB server and forces the
> load of read
> only data in the cache
>
> I'm not sure how you tell clients NOT to call the EJB server
> until the cache
> is loaded but... Also, you will probably need a way to force
> flush/reload of
> specific cached objects if their underlying values are changed in a
> database.
>
> Any reasons why this is not workable in an EJB/servlet
> architecture? I'm not
> convinced that Entity beans are appropriate in this situation.
>
> Regards,
> Mikef
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Ingo Schuster
> > Sent: Monday, January 17, 2000 9:36 AM
> > To: [EMAIL PROTECTED]
> > Subject: Caching of read-only DB contents in an EJB
> >
> >
> > Hi everybody,
> >
> > I'm currently working on my diploma thesis "Application
> > Architectures with the
> > J2EE". One of the issues I want to work on is about database caching. A
> > question I'm currently facing is the following:
> >
> > For performance issues, one could try to cache records of a
> > read-only database
> > in an EJB. However, this might raise some new problems, some
> questions at
> > least:
> >
> > 1. What type of EJB is is best suited for this job: Entity or
> > Stateless Session
> > (Stateful Session doesn't make sense, I think)?
> > 2. If I choose a stateless session bean:
> > - Will I get trouble with timeouts (the container removes the
> > bean and I
> > have to "save the cache")?
> > - The container could create several intances of this session
> > bean or can I
> > make sure that only a certain number is instantiated?
> > 3. Is there an alternative to using EJBs - e.g. servlets ? But in
> > that case my
> > application would needed be accessed through the webtier - a stand-alone
> > application accessing the EJB tier directly couldn't use the
> > caching, right?
> >
> > If anybody has some ideas about this questions, I would be
> > grateful for some
> > help!
> >
> > ingo.
> >
> > ==================================================================
> > =========
> > 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".
