Graph Paging =~ Caching (sort of, but not really)
Christian Bauer called my spade a spade on Dion's blog. He pointed out that I am describing caching behavior, which is true, but it is a cache in the sense that an executing application is an in-memory cache of the binaries on disk.
A better description of that I want is to implement an in-memory database (optimized for storing Java objects) backed by a remote database. I know of at least one effort to do this for relational databases in general, but that is a bigger problem than what I wanted to address, which is simply the same idea for java objects instead of arbitrary relational data (smaller problem set is nice).
There are a few things you would need in order to see a big performance gain. The first is that to see the big performance gains you would need to have the objects capable of participating in optimistic transactions. If they couldn't be optimistic, it would always have to pass through to the backing database in order to maintain transaction semantics there. Luckily, most things can participate in optimistic transactions. The ones that cannot simply always need to pass through.
writebacks...
Hi Brian, What you describe above is exactly what Coherence provides out of the box (and more)! One of the standard caching strategies that Coherence supports is what we call Read-Through/Write-Through or Write-Behind caching where on a cache miss the data is automatically loaded from the underlying datastore (Read-Through). For writes we support synchronous (Write-Through) or asynchronous (Write-Behind). Concurrency is maintained by using our cluster-wide locking feature, so if everyone follows the same lock, get, put, unlock pattern concurrency is guaranteed across the cluster... Take a look and email me if you have any questions (rmisek @ ...).
comment...