SearchBuilder::Record::Cacheable study and call for comments

RT Developers
1

Today, I’ve study the DBIx::SearchBuilder::Record::Cacheable code.

My conclusion is,
the asumption or design goal of this mechanism should change.

Currently, DBIx::SearchBuilder::Record::Cacheable works fine.
But it will make more concurrency and coherence problems than
performance problems it sloved.

A cache mechanism should not return wrong data,
expire conditation or cached-data lifecycle is the key to ensure this.

But, DBIx::SearchBuilder::Record::Cacheable asume

  1. cached-data expire by time-period , default 5 sec.
  2. cached-data lifecycle is as long as apache/mod_perl2 process.

Two case may happen

  1. cached-data updated in 1111 apache/mod_perl2 process, but
    a old copy still in memory of 2222 apache/mod_perl2 process.
  2. In 3333 apache/mod_perl2 process, it serve a HTTP request,
    which just across 5 sec timeframe,
    so a hard luck HTTP request handler prcess,
    may get inconsistency data result.
    If the caller logic depend on this, wrong page content generated.
    and it’s run-time random bug , very hard to find it out.

So, I would like to propose a Change Request, to
make the cached-data lifecycle is exactly equal to the lifecycle of
a Run-Time Request(task?) Process.

On the other words, the goal of DBIx::SearchBuilder::Record::Cacheable
is to eliminate the duplication of SQL queries in a request time frame.

To eliminate the computing cost of the same SQL queries is not the
responsibility of DBIx::SearchBuilder. It should be solved by either
DBI layer or DataBase Server-side.

jihuang

2

Incidently I’ve been thinking about making a new Cacheable.

Limiting the lifespan of the cache to a single request is one good
way to make Cacheable better. Though off the top of my head I’m
thinking it’ll be fairly hard to refactor Cacheable to do that. I
think you’ll basically have to rewrite it, or you could cheat and
clobber both of it’s global stores.

So the new Cacheable I’ve been thinking about would use 'memcached’
rather then trying to do it’s own thing. One of the major perks of
using ‘memcached’ is that the cache can be shared across any number
of processess/threads/servers.

Using ‘memcached’ may also turn out to be really painful with SB.

Matt

3

Incidently I’ve been thinking about making a new Cacheable.

[For those playing the home game, Matt wrote SB::R::Cachable in the
first place]

Limiting the lifespan of the cache to a single request is one good
way to make Cacheable better. Though off the top of my head I’m
thinking it’ll be fairly hard to refactor Cacheable to do that. I
think you’ll basically have to rewrite it, or you could cheat and
clobber both of it’s global stores.

Adding an method to explicitly clear both global stores is very doable.
It’s something that I’ve talked about with a number of folks over the
past couple years, but we haven’t seen hard numbers suggesting that
clearing the whole cache per request was really the right thing to do.
(If you’ve got those hard numbers, I’d love to see them.)

So the new Cacheable I’ve been thinking about would use ‘memcached’
rather then trying to do it’s own thing. One of the major perks of
using ‘memcached’ is that the cache can be shared across any number
of processess/threads/servers.

nod memcached does seem to be a big win here. My only concern is that
everything work reasonably well in the fallback case when there’s no
memcached to use. I’ll also note that memcached and its perl API come
with almost no tests, which doesn’t give me a warm feeling about them.

Best,
Jesse