Hi Andreas,
I too tried using stateless session beans in
my previous project where the data to be cached is
less which worked fine.
But in the current project i need to cache lot
of data maybe it will be upto 30MB or more.I thought
this would be heavy if we put it in a stateless
session bean with multiple instances.Since performance
is paramount to us.Can you explaiin(maybe with some
code, if possible)how you put the data in the servlet
tier in static HashMaps.When the object is initialised
and how will it live in the container(EJB or
servlet).Won't the object die if there are no
references to it?won't the access be slow if multiple
users access a cache object assuming there are
millions of users accessing the cached data??
Since the caching mechanism is cropping up in
different projects,I am reluctant to use vendor
specific implementations which john is
suggesting,maybe we can come up with some general
framework/strategy.
Regards,
Ravi Kakani
--- John Harby <[EMAIL PROTECTED]> wrote:
> I think some vendors are providing assistance for
> these situations. For
> example, the latest Weblogic provides newer
> cache-related mechanisms (such
> as multicasting cache invalidations across clusters,
> etc.) and Websphere 4.0
> has "data access beans" which provide query data
> caching.
> You might want to check and see what your vendor
> supports.
>
> >From: Andreas Maschke <[EMAIL PROTECTED]>
> >Reply-To: Andreas Maschke <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: Weird Caching Questions
> >Date: Tue, 21 Aug 2001 01:42:22 +0200
> >
> > > Jon Dart wrote:
> > > >
> > > > ...
> > > >
> > > > However, this isn't a very common programming
> paradigm. Keep in mind
> >that your database server is going to cache
> frequently read data anyway. If
> >you have a nice fast database server and effective
> connection pooling (so
> >you're not having the overhead of reconnecting),
> you may find that pulling
> >this frequently-accessed data out of the DB is not
> a great deal less
> >effective than pulling it out of your cache.
> > >
> > > I doubt it. We have generally found that such
> caches give 30-40 times
> >the
> > > performance of hitting the DBMS, no matter how
> effective the DBMS cache
> >is.
> >
> >I agree. I think the cache of a DBMS often is
> overestimated. If you fire
> >LOTS of different statements and have LOTS of
> transactions there is a bad
> >chance for the DBMS to cache ALL relevant data.
> >And every database access is a REMOTE access.
> >
> >In our application we use EJBs and Servlets
> (generating HTML). Our forms
> >usually contain lots of list-boxes configured by
> the user. (E.g. creating a
> >customer you may select the country and language
> from a list you defined.)
> >This "listbox-data" is stored like all other data
> in the database because
> >there are relations. (E.g. the country table
> additionally contains some
> >conditions. If you create an order for a customer
> in country XY there are
> >other conditions than in country ABC.)
> >So every time we refresh a form containing customer
> data we have to read
> >the
> >customer data AND to fill all list-boxes with the
> possible values.
> >
> >At first we tried to do this without any explicit
> caching and it was very
> >slow. Later we tried caching in the EJB-tier (both
> using stateless and
> >stateful session beans). The performance was MUCH
> better. But there where
> >problems with multiple instances of the beans.
> >Finally we implemented the listbox-cache using
> static HashMaps in the
> >Servlet-tier and it seems to work very fine. And
> because this cache is
> >created only once per Servlet-Container there is
> the chance to invalidate
> >the cache on demand which is an important feature.
> >I'm not very happy with this architecture from a
> designers point of view.
> >But performance does matter.
> >
> >Regards,
> >Andreas Maschke
> >
> >
> >
> >
> >Andreas Maschke
> >
>
>===========================================================================
> >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".
> >
>
>
>
_________________________________________________________________
> Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp
>
>
===========================================================================
> 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".
>
__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/
===========================================================================
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".
