[ajug-members] Caching frameworks for J2EE applications

[Jason Chambers]

Caching is all about keeping data closest to where it is needed. It is  
first and foremost a performance optimization, however you have to ask  
yourself a couple of questions about the data:

1. Is it read-only, read-mostly or write-mostly?
2. How often does the data change?
3. What is the tolerance in each case for data staleness?

Data that falls into the category of read-only/mostly, has a low rate  
of change and a reasonable tolerance for data staleness are ideal  
candidates for caching.

1.  For caching web-objects for a global web-site, edge caching  
providers such as Akamai are the way to go. This works well for static  
objects such as images, CSS, JS, HTML etc. It moves the content closer  
to the end user. Also, recall that every point across the network may  
have some degree of cache-ability (e.g. proxy servers, routers,  
browsers)
2. Servlets - for HTTP gets, ensure the HTTP cache-control headers are  
set appropriately to reduce trips back to the server when the version  
in the browser cache could be plenty fresh (enough)
3. POJOs - memcached or JBossCache work well. Clustering/cache  
replication may not always be required. Clustering is a good option if  
the data source is the end-user - if the data source is a database,  
you can recover the cache quite easily - if the data source is the end  
user, you cannot very well ask them, "My cache seems to have gone down  
the toilet taking your session information with it - tell me again,  
how many shares of IBM did you want to buy again? (sorry)"
4. Data from EIS and RDMS - this is where caching on the app server  
really shines - you can reduce a significant amount of load on back- 
end resources through caching - but only if the data is a good  
candidate for caching. Hibernate/eh-cache may work pretty well here in  
addition to memcached and JBossCache.

Oracle Coherence in my opinion has evolved way beyond it's caching  
roots. Using Coherence, you can build a huge data grid across  
commodity hardware. Each node in the grid has it's share of  
responsibilities and is backed up by n other nodes for redundancy.  
Operations against the data can move to where the data is rather than  
move the data to where the operation occurs (our traditional way of  
approaching data processing for the past gozillion years).

Jason

On Jul 22, 2008, at 2:02 PM, David Page wrote:

> Sounds like a job for ehcache.
>
> On Tue, Jul 22, 2008 at 1:32 PM, <VKulandaivel at inautix.co.in> wrote:
> Would like to cache
>
> 1. Front GUIs (Typically JSPs, SWFs, etc)
> 2. Servlets
> 3. POJOs
> 4. Data from EIS as well as RDBMS
>
> Wish to spend some $$$ if that's really worthy.
>
> Regards
> Vinay
>
>
>
>
>             "Rob Worsnop"
>             <rworsnop at gmail.c
>              
> om>                                                        To
>                                       ajug-members at ajug.org
>             07/22/2008  
> 01:07                                           cc
>             PM
>                                                                    
> Subject
>                                       Re: [ajug-members] Caching
>             Please respond to         frameworks for J2EE applications
>             ajug-members at ajug
>                   .org
>
>
>
>
>
>
>
>
> For a clustered environment? If so how many nodes do you want to  
> scale to?
> What will you be caching? Is it session-specific?
> Open source only, or do you have $$$ to spend?
>
> On Tue, Jul 22, 2008 at 12:05 PM,  <VKulandaivel at inautix.co.in> wrote:
> >
> > Folks,
> >
> > Any suggestion or experience to share something about my subject  
> over
> here.
> >
> > Regards
> > Vinay
> >
> >
> > _______________________________________________
> > ajug-members mailing list
> > ajug-members at ajug.org
> > http://www.ajug.org/mailman/listinfo/ajug-members
> >
>
> _______________________________________________
> ajug-members mailing list
> ajug-members at ajug.org
> http://www.ajug.org/mailman/listinfo/ajug-members
>
>
>
> _______________________________________________
> ajug-members mailing list
> ajug-members at ajug.org
> http://www.ajug.org/mailman/listinfo/ajug-members
>
> _______________________________________________
> ajug-members mailing list
> ajug-members at ajug.org
> http://www.ajug.org/mailman/listinfo/ajug-members

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ajug.org/pipermail/ajug-members/attachments/20080722/c9d9e8c5/attachment.html