CS848 Paper Review Form - Fall 2006
Paper Title: A scalability Service for Dynamic Web Applications

Author(s): A. Ailamaki, B. Maggs, T. Mowry

1) Is the paper technically correct?
 [X] Yes
 [ ] Mostly (minor flaws, but mostly solid)
 [ ] No

2) Originality
 [ ] Very good (very novel, trailblazing work)
 [X] Good 
 [ ] Marginal (very incremental)
 [ ] Poor (little or nothing that is new)

3) Technical Depth
 [ ] Very good (comparable to best conference papers)
 [X] Good (comparable to typical conference papers)
 [ ] Marginal depth
 [ ] Little or no depth

4) Impact/Significance
 [X] Very significant
 [ ] Significant
 [ ] Marginal significance.
 [ ] Little or no significance.

5) Presentation
 [X] Very well written
 [ ] Generally well written
 [ ] Readable
 [ ] Needs considerable work
 [ ] Unacceptably bad

6) Overall Rating
 [ ] Strong accept (very high quality)
 [X] Accept (high quality - would argue for acceptance)
 [ ] Weak Accept (marginal, willing to accept but wouldn't argue for it)
 [ ] Weak Reject (marginal, probably reject)
 [ ] Reject (would argue for rejection)

7) Summary of the paper's main contribution and rationale
   for your recommendation. (1-2 paragraphs)

The main contribution of this paper is that of a presenting a distributed caching 
technique which has the potential of providing a dynamic ("on-demand") and scalable 
solution for periods of high work load. The technique presented is to have a number of 
cache proxies co-located with edge servers to reduce the number of read-only queries 
sent to by the primary ("in-house") database.

My reasons for accepting this paper are two fold:

A) Practical Significance
As the paper suggests this caching technique provides a way for smaller oragnizations
to prepare in advance for sudden surges in DB work load. Consequently data centers and
service providers would very be interested in providng such solutions which 
small to medium DB owners could benefit from. Publishing this paper will provided
momentum towards that end 

B) Research Implications
The paper opens the door for future research in this area. For example it 
sets the ground work for categorizing view invalidation strategies and their usability
in different scenarios.  The only concern which makes this paper short of one the best ones 
is the technique of analyzing application code to form query templates, which in my opinion 
is impratical. But publishing this paper and encouraging future work should perhaps
bring up simpler more practical solutions to light. 



8) List 1-3 strengths of the paper.  (1-2 sentences each,
identified as S1, S2, S3.)

S1 - A novel idea was presented along with a basic prototype 
proof-of-concept from which benefits of emplyoing the presented caching
technique were evident.

S2 - Future implications and current limitations of the technique
were very clearly identified.	 


9) List 1-3 weaknesses of the paper (1-2 sentences each,
identified as W1, W2, W3.)

W1 - Analysis of code and query analysis to form templates in the technique 
presented is a major impractical limitation.

W2 - The issue of the query/update indepedence mapping and its undecideability
was brushed aside in an an effort to focus on correctness. This may pose significant
problems in applications with a very large amounts of SQL usage.

W3 - No comprehensive conclusion was offered other than that the idea of 
distributed caching is promising. (Perhaps because this paper was part of 
an ongoing project)



10) Detailed comments for authors.

- The paper had slightly confusing ordering of discussing topics. Most disorienting was
the fact that the so called "outline" was presented very late in the paper.

- A lot of issues were touched in this paper and most of the interesting questions
brought forward were left as future work. It would have been nice to consider one 
and address it thoroughly.

- One issue which was not mentioned was "cachability" of a particular
query and query subscription models. Since many proxies are expected to subscribe 
to view invalidations, the decision to "cache which view/query where" has to be made. 
What is the criteria and what are the implications? Is it application dependent?