Paul van den Bogaard wrote:
> For the ones you
> describe could it be that the dbase layer is just storage and not part
> of the (critical) performance path?
Right, in our case we keep all state in memory as the primary
representation (and maybe replicated across a cluster) and some specific
state is also asynchronously written to disk via a RDBMS so that it
survives a cluster restart. Performance of the write-back step is still
important as it affects things like our MTTR from a complete
database+cluster failure, but it does not directly affect the call
throughput / latency.
> If the database related work is critical in performance/throughput than
> caching is a welcome technology.
Well no not necessarily because *statement caching does nothing that you
can't do directly in your application anyway*. For example in our case
we would get no additional benefit from statement caching because we (as
a JDBC client) already hold on to statement objects that we know we're
going to reuse, i.e. we're already doing our own caching, and smarter
than a generic layer can do because we have better knowledge of how we
use our queries.
Statement caching is really a "go faster" switch when you don't want to
(or cannot) optimize the application code, or where the exact query
strings are unpredictable. But again it's not something that *has* to be
implemented in the driver, as far as I can tell there's nothing there
that can't be done by a layer between the client and the real driver.
-O
