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