Hi Julius,
<?xml version="1.0" encoding="UTF8"?>
<!DOCTYPE SEQUOIA PUBLIC "-//ObjectWeb//DTD SEQUOIA 1.0.4 //EN"
"http://sequoia.objectweb.org/dtds/sequoia-1.0.4.dtd";>
Which version of Sequoia are you using exactly?
2007-05-02 15:32:53,160 DEBUG virtualdatabase.VirtualDatabaseWorkerThread.mydb
statementExecute command
2007-05-02 15:32:53,163 DEBUG sequoia.controller.RequestManager Processing
macros in request 57 (select count(*) from POOL_COLLECTION_DATA_21/)
2007-05-02 15:32:53,163 DEBUG sequoia.controller.RequestManager Macros
processed in request 57, new request is: select count(*) from
POOL_COLLECTION_DATA_21/
2007-05-02 15:32:53,164 DEBUG controller.RequestManager.mydb Broadcasting request
select count(*) from POOL_COLLECTION_DAT... to all controllers
(Member(address=/128.141.128.146:44997,
uid=128.141.128.146:44997)->[Member(address=/128.141.128.146:44997,
uid=128.141.128.146:44997)])
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()).
One solution is to use executeQuery() instead execute().
Note that if you force the transaction isolation level to SERIALIZABLE,
all reads will be systematically broadcast.
Hope this helps,
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
