[Rt-devel] SearchBuilder::Record::Cacheable study and call for comments

[June-Yen Huang]

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