> From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
> Sent: 12 June 2002 16:29
>> Agreed, but he wasn't talking about storing the results, just the
query
>> parameters and current offset / number of rows, which is a-ok for
>> putting into a session.
> No, that's exactly what ISN'T okay for putting into a session. If a
> user opens two browser windows, does a search in each, and then pages
> forward in each set of results, he will get completely wrong pages if
> you do this. The query parameters from the first search will be
written
> over and lost.
Please - s/session/Apache::Session/g above
> You could do that, with a unique ID for each set of parameters, but
you
> might as well just put the parameters right in the link unless they're
> very long.
The [Apache::]session approach makes it easy to store and change lots of
params to the query. It also lets you keep track of [recommendedly]
minimal info about the Query on the server, without having to re-execute
it, and it lets you pick up a previous query, with minor tweaks things
like /query?query_id=12345&order=value+desc where the tweak doesn't get
lost in the params.
>> Don't mix transient query sessions with a User Session that stores
info
>> about the user's logged in state etc. It would be normal for one user
to
>> have multiple queries in a login session
>
> Hold on, I think we actually agree, but you're using the word session
> for a bunch of different things. What you're saying here sounds like
> the opposite of what you said above. In common usage, a session is
the
> state of the user's interaction with the application. A cache of
query
> data would be something else.
Again, please s/session/Apache::Session/g
> MySQL is fast, but usually not as fast as simple disk access.
> Cache::Cache and Cache::Mmap handle the details of the cache stuff for
> you, making it pretty easy.
<RANT>
I do agree that disk access _can_ be faster, but disagree with the
implication that caching DB results outside the db is a cool trick. I
would assert that in all general circumstances caching DB results is a
Common Mistake. Special circumstances do exist, but in my experience
very rarely, and that's why we have MI6. I can imagine a circumstance
where a cache may prove useful - a large number of concurrent users, all
wanting exactly the same data, slow db connection, non-optimisable
query. This doesn't seem to be the case here where the question was
about a faster Apache::Session.
Interestingly MySQL and other DBs are often as fast as simple disk
access - contrary to popular wisdom, most DB engines actually cache in
memory, with more data access information and hence effective cache
memory usage than is available to external cache components. Yes,
Network transference can be an issue - but hey! be a masochist, buy a
switch!
I recall an impressive chap at a bank, who was asked to address
performance issues. He immediately identified DB queries as taking far
too long, and proceeded to hand craft a mega-smart shareable multi-user
in-memory cache server in C. He ran into dozens of issues, which were
ingeniously solved using the tersest possible sin tax. After about six
months of effort, the performance problem still existed, mmmm - the DB
resided entirely in memory anyway! A tweak of the schema [i.e. about 2
hours including test and release] by a DB admin took the problematic
process from 2 hours down to 120 seconds. We spent cash for cache, and
lived to rue the day.
I parse 'use a cache for db stuff' as 'my XYZ cache component is way
smarter than all the guys at 'Oracle|Sybase|MySQL' combined', or 'I know
my data better than the database, cos I'm a kewl Koder'. Actually, I
really parse 'use a cache for db stuff' as 'I don't really understand
databases, 3NF and indexing, and can't be bothered learning to use them
well'.
</RANT>
But ok then, use a cache for your mod_perl query parameters, but don't
call it an [Apache::]Session.
8-)
