[ https://forge.continuent.org/jira/browse/SEQUOIA-1003?page=comments#action_14149 ]
Emmanuel Cecchet commented on SEQUOIA-1003: ------------------------------------------- As it is written in the doc (http://sequoia.continuent.org/doc/latest/userGuide/ar01s05.html): 'Streamable ResultSets do not work properly in autocommit mode as the connection used for retrieving the ResultSet is handed back to the pool. The workaround is to always encapsulate the query in a transaction. Note that databases such as PostgreSQL do not support streamable ResultSets in autocommit mode as well.' The issue is that you will need additional mechanisms to cleanup ControllerResultSets in case of a client failure. If you are in a transaction, the transaction cleanup procedure takes care of it. You will have to implement a similar mechanism when in autocommit mode. Moreover, it is possible to use read proxying in case the controller you are connected to has no backend enabled (the read request is then forwarded to a remote node). Detecting the client failure in such scenario is more complex and will require additional cleanup mechanism if you don't want to end up with a memory leak with ControllerResultSets. > Fetch size hints result in null pointer exception for autocommit reads > ---------------------------------------------------------------------- > > Key: SEQUOIA-1003 > URL: https://forge.continuent.org/jira/browse/SEQUOIA-1003 > Project: Sequoia > Type: Bug > Versions: Sequoia 2.9 > Environment: All, confirmed using MySQL. > Reporter: Robert Hodges > Assignee: Robert Hodges > Fix For: sequoia 2.10.10 > > > Sequoia set fetch size processing does not work properly for autocommit > reads. The problem is that when using set fetch size you must hold onto the > connection until all results have been read out. However, the current > behavior of Sequoia is that for autocommit requests the connection is freed > after doing a select. This means that either the connection will be logged > out or reused if it takes a while to fetch back results. > To illustrate the problem approximately, ensure the VDB has a table with at > least 10 rows. Login using the console and enter the following commands: > > fetchsize 5 > > select * from yourtable > The console will ask you to press enter to see more results. Go away for a > few minutes before presssing enter so that the connection pool will drop or > reuse the connection. You should now get a null pointer exception. > For an example of misbehaving code, see RAIDb1.executeRequestOnBackend(), > which invokes code to run a select then immediately gives up the connection: > rs = executeStatementExecuteQueryOnBackend(request, backend, null, c > .getConnection(), metadataCache); > cm.releaseConnectionInAutoCommit(request, c); > The fix for this problem is to cache the connection in the ControllerResult > set and release it when finished reading the underlying result set. > NOTE: There is no problem when running reads within transactions. In this > case the connection will be held until there is a commit or rollback > statement. Unfortunately this problem is quite serious for native > applications especially once it is possible to set the fetch size using a > connection property. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://forge.continuent.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
