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