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
--
Emmanuel Cecchet
Chief Scientific Officer, Continuent
Blog: http://emanux.blogspot.com/
Open source: http://www.continuent.org
Corporate: http://www.continuent.com
Skype: emmanuel_cecchet
Cell: +33 687 342 685
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
