Debate — App server caching

Debate is a new Dagblog column in which I’d like to hear 
 readers’ views on technical topics. Anyone can help choose the topics. 
 Just write to me with a suggestion and your own view if you have one. To kick off
 the column I’ve chosen caching data on an application server. I originally tried 
 the discussion groups at java@builder.cz
 and konference@java.cz, but didn’t get much of a response.

I’d be interested in approaches to caching data on an application server. Let’s say 
we have a conventional web application that gets data through JDBC. The problem is 
that the business logic calls for some particularly tricky things, so the SQL 
queries are very demanding and run over a large volume of data. A lot of users 
use the web application, so the load on the SQL server keeps climbing 
and overall application response times get worse.

Can we change that setup to take the pressure off the SQL server? 
My view is that we can’t get the effect we want without adding a layer between the database and 
the application logic. Its main job would be 
to cache data (I’m not talking about ORM). The layer’s clients, 
in our case the business logic itself, would use this layer instead of writing SQL 
for the data we decide to cache. The layer would of course contain 
predefined SQL to do the actual work of pulling the data out of the database.

Suppose we have a query that returns data for a list of people. 
The columns in the SELECT could be used to create an 
Osoba (Person) object. We can then cache that object because it will basically 
be a POJO. I took a quick look at JCS
and it reinforces that view.