Please don't depend on h2database for caches

[GoogleCodeExporter]

While packaging Gerrit for Debian I'd really like to avoid having to package 
h2database too. H2 does not look appealing at first sight:

- home grown build system
- home grown documentation system
- not much automation in the release process?

It looks like it would be trivial to build a persistent cache on the filesystem 
with the creation time saved in the filesystem meta data and the key in the 
file name. Isn't there some code in jgit that could be reused for that?

On the other hand it is written in the commit message that the cache should 
only hold 128M of data. That should fit nicely in memory, shouldn't it? Why 
bother with a persistent cache for 128M?

Regards, Thomas Koch

Original issue reported on code.google.com by thkoch2001@gmail.com on 1 Sep 2012 at 1:15

[GoogleCodeExporter]

A persistent cache has the advantage that it survives a Gerrit restart.

Original comment by edwin.ke...@gmail.com on 3 Sep 2012 at 6:43

[GoogleCodeExporter]

@edwin: I'm surely aware that a persistent cache is supposed to be persistent.

My question is rather whether these 128M of data are so hard to reproduce that 
they couldn't be created (probably lazily) after each restart of gerrit and 
then remain in the JVM's heap?

You don't really restart your gerrit instance every day, do you? So the 
recreation of the cached date shouldn't happen often.

Original comment by thkoch2001@gmail.com on 3 Sep 2012 at 2:51

[GoogleCodeExporter]

Of course Gerrit restarts do not happen often and I also don't see a problem 
with lazily recreating this data if the cache is not persistent.

Original comment by edwin.ke...@gmail.com on 4 Sep 2012 at 5:42

[GoogleCodeExporter]

The web sessions are kept across restart by tracking them in a persistent 
cache. That needs to be replaced or handled some other way to keep users logged 
in across a server restart.

The diff cache is fairly small, but just because the data it holds is small 
doesn't mean the data was fast to compute. We try to reuse the diff cache 
across restarts because building the entries can take half a second or more, 
per entry. That is an ugly latency that we try to hide from users when possible 
by using that cache entry. The tag cache is also small, but can take 45-90s to 
rebuild an entry.

Admins can disable disk based caching, the H2 code still has to be there at 
compile time. So we need to make it possible to build without the H2 cache. We 
should also make the web sessions not be tied to the cache being persistent 
across restarts. Martin and I talked about that on #gerrit a few weeks ago.

Original comment by spea...@spearce.org on 4 Sep 2012 at 3:52