On Tue, 28 Sep 2004, Kazuho Oku wrote:
>Thank you for the response.
>
>Unfortunately, my apache module only performs a single SELECT clause of
>which WHERE clause can be indexed.
>What I am wondering is the way to stop calling SQLite each time the module
>processes an HTTP request (eliminate the FLOCK -> READ -> FUNLOCK done by
>SQLite).
Is this an actual bottleneck? Against internet latencies, this is likely
not to be that big a win.
It will not be significantly slower than any other filesystem operation,
such as checking for an indicator file, especially if you then remove the
indicator file (synchronous disk operations!)
Does the cache have to be in sync with the current database all the time.
ie. Would it be satisfactory to simply check the database once per second,
and only update the cache then? This would certainly reduce any SQLite
overhead significantly.
You're better off (IMHO) just sticking with any performance hit and
communicating via the database until DRH has updated the page cache to
maintain state across transactions.
># sorry for my poor English...
>
>From: "Paul Smith" <[EMAIL PROTECTED]>
>
>> What I've done here is have a table in the database with a single value
>> containing the 'update id' in it. Then, I've got SQLite triggers set on
>> UPDATE, DELETE and INSERT for the main data tables. These triggers
>> increment the 'update id' whenever the main data tables get updated. My
>> cache routines check the 'update id' table to decide whether the cached
>> data is still valid.
>>
>> It seems to work OK here (where data is read much more than it is
>written).
>> If data was being written frequently, then the trigger could potentially
>> slow those down too much.
>
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
