Caching

[Dan Mullins]

Has anyone had any great success using a caching tool such as
Terracotta/OSCache/EhCache, etc..?

What kind of problems were you running into?

What kind of problems did it introduce?

Dan

[Travis Klotz]

Dan,


What are you actually trying to do? EHCache and OSCache really are
caching frameworks (I think EHCache has won this particular battle
with JBoss Cache also having a large amount of mind-share) But
Terracotta is really a clustering framework/application that can sort
of be used for things like Hibernate caching as well.


Travis

> --
> Visit http://www.cijug.net for more information
>
> You received this message because you are subscribed to the Google Groups "Central Iowa Java Users Group" group.
> To post to this group, send email to Central-Iowa-J...@googlegroups.com
> To unsubscribe from this group, send email to Central-Iowa-Java-Us...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/Central-Iowa-Java-Users-Group?hl=en

[Oscar Rodríguez]

NO

[Aaron Korver]

I've implemented EhCache in many different apps.  I can't think of any that had negative side-effect, but all had positive side-effects.  In almost all cases, it was used to cache resources which were expensive to retrieve/construct, but cheap to keep in memory.  Also items that were a high read/low write ratio are good candidate for cache use.  Most of the implementations decorated an existing service and would check the cache for the requested object before requesting it from the service itself.

So in summary, no negatives (except a larger memory footprint of the app), and no problems introduced.

The only other thing I can think of is that the cache take a bit to get primed.  So if your users are used to a certain level of performance with caching, and the app gets restarted (and the cache is not persisted), then until the cache is primed, the performance of the app is slower.

Thanks,
Aaron

On Mon, Nov 16, 2009 at 12:51 PM, Dan Mullins <dmull...@gmail.com> wrote:

[Hansen, Tony E]

Using these frameworks,how does one counter for stale or ophaned objects or are you caching basic configs? per person? per session?  More generally, could someone describe how one might use such a framework?

 

Thank you, Tony

---

From: Aaron Korver [mailto:aaron....@gmail.com]
Sent: Monday, November 16, 2009 1:31 PM
To: central-iowa-j...@googlegroups.com
Subject: Re: [CIJUG] Caching

[VDej...@wrberkley.com]

Return Receipt

Your RE: [CIJUG] Caching
document:

was VDej...@wrberkley.com
received
by:

at: 11/16/2009 01:41:55 PM








*************
CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain private, privileged and confidential information belonging to the sender. The information therein is solely for the use of the addressee. If your receipt of this transmission has occurred as the result of an error, please immediately notify us so we can arrange for the return of the documents. In such circumstances, you are advised that you may not disclose, copy, distribute or take any other action in reliance on the information transmitted.

[Dan Mullins]

The biggest downside (IMO) is keeping the cache in sync with the real data.

I know you should only cache things that return a high "cache hit
rate". So, lookup tables? If you use hibernate, then you have the 2nd
level and query cache. But if you cache an actively changing table,
you would constantly be flushing and reloading the cache. And
hibernate wouldn't catch changes made directly to the database.

I guess the better question is, what are the characteristics of an
application that would be benefited by caching?

Dan

[Aaron Korver]

Lookup tables is a good one.  The classic example of a web form with the list of US States on it.  If the decision has been made prior to keep the states in the DB, then the form pulls the state list from the DB.  Well, it more than likely isn't going to change, so placing that list in the cache, and pulling from the cache vs the DB call saves a trip to the DB, and usually speeds up the form creation on the server side.

[Travis Klotz]

My general rules for caching are:

1) Only cache read-only data

2) Only cache read-only data for a short period of time (5-30 min)
because no data is really ever read-only and its really annoying to
have to bounce all your apps when a lookup table changes


Caching frequently changing data ends up being very difficult, even
with frameworks like ehcache. Once your application starts to do this,
then it becomes the only application that is allowed to change the
cached data, no exceptions for ad-hoc tools like sql/plus, TOAD, etc.
If your app is up, its the only thing that can safely change the data.
And all instances of your application must share the same cache, that
means using a clustered cache which always ends up being way more work
than you think it should be.

These are very large, painful restrictions that most of us have never
had to work under. Lots of simple, only the fly fixes and extensions
simply are not possible. Make sure you know what you are getting into
before your companies application adds an order of magnitude to its
complexity.


Travis

[Brandon Carlson]

I like these. I'd probably add in one more:

1.5) Prove to me that the reason your app is slow is because of the
seek time on the DB tables. DB Engines do a great job of caching stuff
these days and quite often the bottleneck isn't in your lookup tables
so you're really adding complexity for a nominal return.

[Travis Klotz]

That is a very good thing to remember. Databases aren't magic, they
read sequential files off disk just like we would if we didn't have
them. But they do an insane amount of caching, much better, more
specialized than anything we would ever build on the app server, so
let the database do the caching for as long as you can, it will do it
better than Hibernate + Caching Framework X anyways.


Travis

[Octavian Covalschi]

I would say it's case by case... I don't see any issues by caching everything I can, unless caching operation is expensive...

Cache the most used data, and keep it forever.. reload cache if data was updated.... it's a matter of catching update event...

One answer to Dan's question would be 2 examples, lifejournal and facebook. They're both using memcached, why ?
Because it's fast and scalable (you can hook as many servers you want.. your memcached client should take care of it).

Anyway, it's case by case.

On Mon, Nov 16, 2009 at 2:39 PM, Travis Klotz <travis...@gmail.com> wrote:

[David Delivante Gifford]

Another good resource from a different perspective.....web cache

Caching Tutorial

http://www.mnot.net/cache_docs/

[Gervase Gallant]

Normally I only work with read-only caches of domain objects, but in certain business situations, particularly where you have moderately static data, you can get into writable caches.... which is some real fun.

I did one of these a while ago, long before JSR 107, on a clustered web application. :eek:

Although Ehcache is very sweet, there's nothing like a roll-your-own implementation! It's sort of like deciding you need to cross the country, but have to build a vehicle to get you there! Will it be a train, a jeep or a bicycle?

This was even before weak and soft reference Maps, so you can imagine it must have been a little dicey on memory. To get around it, we had a Listener that inspected and ejected older content.

I wrote a little article on it http://www.javazoid.com/Cache.html

Looking at it now, I'm a little confused about how it could even work... but it apparently did for a long while.

Gervase

--- On Wed, 11/18/09, David Delivante Gifford <openx...@gmail.com> wrote: