Do you use Statement.execute() or Statement.executeQuery()?
Hmm, I was originally testing with my employer's Java product, which I
didn't write, so I'm not sure. I will look and report back. For now
though I've been testing with the sql client using console.sh. I have
some more information, maybe this will help track this down. I've
been digging through code all day :-).
I seem to be running into problems in two different areas:
1. RequestManager only checks the cache if the Request is marked read-
only.
In org.continuent.sequoia.controller.requestmanager.RequestManager,
method statementExecuteQuery(), line 572:
if ((resultCache != null) && (!request.isMustBroadcast()))
isMustBroadcast() checks if the request isReadOnly or not. So the
above check says if only check the cache if the query is read only.
isReadOnly on SelectRequest defaults to false, but can be changed by
the jdbc client with a setReadOnly command.
Now, I'm not yet sure if all the queries I'm testing from my Java app
are either not setting this (maybe this has to do with your question
execute() vs executeQuery()), or Sequoia isn't setting it (should it?
upon seeing it's just a select query? not sure), or if the cache is
getting checked but I'm actually being bitten by the next problem.
I do know from the sql client using console.sh that the read only flag
is not getting set by default, but I found I could force it by doing a
"setreadonly true". And once I figured out how to force Sequoia to
check the cache every time, I ran into the next, more important,
problem.
2. RequestManager will not cache results from a request that is marked
uncacheable, and there is only one case in SelectRequest where a
request could by marked as cacheable: line 1014, which will only run
if you've picked granularity column or columnUnique (line 354). And I
can't seem to get this part to work. I've tried using both column and
columnUnique. As I step through SelectRequest.parse and
SelectRequest.getWhereColumns, for some reason as it loops over the
DatabaseTables, there are no columns on the table (line 872). This is
where I've stopped for the day.
I must be misunderstanding the code, is this true? It would mean
select results with granularity database or table would never be cached.
So what's happening to me is, even when I can force read-only and have
Sequoia check the cache, the cache is empty (of course, it would be
the first time), so it executes the query in the database, but then
decides the results are not cacheable and doesn't update the cache.
And so on. Now maybe I'm misunderstanding the code, or I missed
something, but logically my simple query of:
select username from person where id = 1
should be cacheable.
I will work to simplify my testing. I'll try a really simple schema
with hsql instead of postgres. Thanks for the help!
Steve
On Jan 25, 2008, at 4:38 PM, Emmanuel Cecchet wrote:
Steve,
Another issue might be the way you execute the query on the client
side.
Do you use Statement.execute() or Statement.executeQuery()?
If I remember well, cache might not work with Statement.execute()
but only with executeQuery().
Hope this helps,
Emmanuel
Thanks for the response! Here's what I've tried (see below), none
of these (and more) seem to be causing any caching. Also, strange,
I enabled DEBUG level logging on
log4j.logger.org.continuent.sequoia.controller.cache=DEBUG,
Console,Filetrace
but only saw the following line printed twice, no other DEBUGs:
2008-01-25 12:33:39,469 DEBUG Trace.java:69 - Cache is empty. I
sleep.
So I thought I'd do a little digging into the code. Using this
config:
<ResultCache granularity="table"/>
I fired up the Controller using jdb and set up breakpoints for
every method in ResultCache and ResultCacheTable. I started up the
process, and in another window started up my virtualdatabase. I
did get a few stop points while the vdb was loading, but none when
I tried my "select ..." statement. Very weird. It's like the
caching code is never being called.
About RelaxedCaching timeout, could you double check that this
value is not in milliseconds? In that case that would mean keeping
the entry of the cache for less than a second and explain the
cache miss.
Yes, I took a look at sequoia/src/org/continuent/sequoia/controller/
cache/result/ResultCacheFactory.java and I see now that the timeout
is in ms. The dtd doc should be updated, it says seconds.
I will post back as I find more, thanks for the suggestions...
Steve
<ResultCache granularity="table">
<DefaultResultCacheRule timestampResolution="60000">
<RelaxedCaching timeout="600000" keepIfNotDirty="true"/>
</DefaultResultCacheRule>
</ResultCache>
<ResultCache/>
<ResultCache granularity="table"/>
<!-- from rubis-cache-database.xml -->
<ResultCache granularity="database" maxNbOfEntries="0"
pendingTimeout="0">
<DefaultResultCacheRule timestampResolution="36000">
<EagerCaching/>
</DefaultResultCacheRule>
</ResultCache>
<!-- from rubis-cache-table.xml -->
<ResultCache granularity="table" maxNbOfEntries="0"
pendingTimeout="0">
<DefaultResultCacheRule timestampResolution="36000">
<EagerCaching/>
</DefaultResultCacheRule>
</ResultCache>
On Jan 25, 2008, at 12:27 AM, Emmanuel Cecchet wrote:
Steve,
<ResultCache granularity="columnUnique">
<DefaultResultCacheRule timestampResolution="1000">
<RelaxedCaching timeout="600" keepIfNotDirty="true"/>
</DefaultResultCacheRule>
</ResultCache>
columnUnique is not supported anymore, you should try with 'table'
first.
About RelaxedCaching timeout, could you double check that this
value is not in milliseconds? In that case that would mean keeping
the entry of the cache for less than a second and explain the
cache miss.
Keep us posted with your finding,
Emmanuel
--
Emmanuel Cecchet - Research scientist
EPFL - LABOS/DSLAB - IN.N 317
Phone: +41-21-693-7558
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
--
Emmanuel Cecchet - Research scientist
EPFL - LABOS/DSLAB - IN.N 317
Phone: +41-21-693-7558
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
