Hi,
I've managed to modify the source so that now Sequoia doesn't broadcast
and use cache. My modifications are probably (surely) not correct, but
they made it work with our application.
My changes:
1) I force AbstractRequest.isReadOnly = true
2) I commented in RequestManage.statementExecuteQuery(..):
scheduler.readCompleted(request);
(otherwise it throws exception after cache hit)
Julius
Julius Hrivnac wrote:
Hi,
I've managed to force Sequoia not to broadcast (adding an ugly trick
in the source code), but I'm still not able to use cache, even in the case
of SingleDB. I've tried also with rubis examples (modified) - no success.
Could anyone help me, what I'm doing wrong ? I print out
request.toDebugString():
Request id: 1
query: SELECT * from collection_aida_100a
login: test
autocommit: true
transaction id: 1
cacheable status: CACHEABLE
isolation level: TRANSACTION_READ_COMMITTED
start time: 1179327707986
end time: 0
timeout in seconds: 0
persistent connection id: 0
client ip address: 127.0.0.1
The log says:
17:04:42,936 DEBUG controller.core.Controller Starting new
ControllerWorkerThread
17:04:42,938 DEBUG controller.core.Controller Connection from
/127.0.0.1:33325
17:04:42,939 DEBUG controller.core.Controller Starting new
VirtualDatabaseWorkerThread
17:04:42,940 DEBUG virtualdatabase.VirtualDatabaseWorkerThread.mydb
Login accepted for test from 127.0.0.1
17:04:42,942 DEBUG virtualdatabase.VirtualDatabaseWorkerThread.mydb
SetTransactionIsolation command (level=2)
17:04:42,951 DEBUG virtualdatabase.VirtualDatabaseWorkerThread.mydb
StatementExecuteQuery command
17:04:42,952 DEBUG controller.RequestManager.mydb Scheduling read
Request (2): SELECT * from collection_aida_100a
17:04:42,957 DEBUG controller.RequestManager.mydb Load balancing read
request (2): SELECT * from collection_aida_100a
17:04:42,962 DEBUG controller.RequestManager.mydb Updating cache with
read Request (2): SELECT * from collection_aida_100a
17:04:42,962 WARN sequoia.controller.cache Unable to remove pending
query test,SELECT * from collection_aida_100a
17:04:42,963 DEBUG sequoia.controller.cache Adding query test,SELECT *
from collection_aida_100a to cache
17:04:42,963 WARN sequoia.controller.cache Modifying the result of a
valid entry in the cache (test,SELECT * from collection_aida_100a)
17:04:42,964 WARN sequoia.controller.cache No parsing of select clause
found - Fallback to table granularity
17:04:43,107 WARN virtualdatabase.VirtualDatabaseWorkerThread.mydb
Client (login:test,host:localhost.localdomain closed connection with
server)
Anybody could help me ?
Julius
Emmanuel Cecchet wrote:
Hi Julius,
Which version of Sequoia are you using exactly?
3.0-beta2
There was a bug in this version. You can try out with 3.0-beta3 but
the Gorda code does not seem fully stable yet.
You can checkout CVS tag named HEAD_BEFORE_GORDA_COMMIT if you want a
more stable version. If you don't want to recompile from the source,
you can try out build 61 from
https://forge.continuent.org/builds/sequoia/BUILD-61/
Your application uses Statement.execute("select ...") instead of
Statement.executeQuery("select ...").
The controller tries to check the content of the SQL statement to
see if it is a plain SELECT and then tries to optimize it to execute
it on a single backend. For some reason (that I don't explain yet),
the statement is not detected as a plain SELECT statement and thus
it is broadcast (because of Statement.execute()).
And it doesn't use cache for the same reason ?
Yes, queries that are broadcast cannot be cached (because if they are
broadcast, it is that they have a side effect on each database).
One solution is to use executeQuery() instead execute().
I have no control over executeQuery()/execute() choice (it's not
my code). Is there anything else I could do (maybe ob the Sequoia
side) ?
The problem certainly resides in the class VirtualDatabaseWorkerThread
around line 2369 where we call "if
(requestFactory.requestNeedsExecute(request))", this call returns true
instead of false. You should try to track why.
But first you can use a more recent built to see if the bug is still
there.
Thanks for your feedback,
Emmanuel
--
Experience is very important
- it helps you recognize a mistake when you make it again.
########################################################################
Are they serious ? - <a href="http://hrivnac.free.fr/Islam";>
########################################################################
# E-mail: [EMAIL PROTECTED] #
# WWW: http://cern.ch/hrivnac #
# My Space: http://www.myspace.com/juliushrivnac #
# Lide.cz: http://www.lide.cz/Julius.Hrivnac #
# S-mail: LAL, BP 34, F - 91898 Orsay cedex, France #
# phone: (F)-(0)1-64-46-82-51; private: (F)-(0)8-71-19-31-70 #
# mobil: (F)-622-741-151; (CZ)-607-918-415 #
# ICQ: 10804323 #
# AIM: jhrivnac #
# Skype: jhrivnac #
# Jabber: JuliusHrivnac #
########################################################################
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
