As a 'live' example, in a recent project we used stateless SBs (Singletons)
that cached 2 different kind of resultsets (we used our own 'disconnected'
resultset for it):
- user-specific, small resultsets. Things like login-information and
user-preferences. The resultsets are not very big (say 5k max), so we could
affort to store it for each user (even with 10.000 registered users it
still is only 5mb).
- large, often used queries that were not user-specific. In your case, it
would be 30mb * 10.000 users = almost 300Gb. We thought that was too much.
Large, userspecific resultsets were not cached.
For most parts of the site, the performance is very good. Only the
user-specific, big resultsets are unfortunately rather slow.
> 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".
>
>
===========================================================================
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".
