[ https://forge.continuent.org/jira/browse/SEQUOIA-1003?page=comments#action_14150 ]
Robert Hodges commented on SEQUOIA-1003: ---------------------------------------- Thanks for the comments. I had a very similar set of concerns but had not thought about the case where read requests are forwarded. I would think, however, that we need to deal with these problems anyway because if ControllerResultSets don't get cleaned up that is a very serious resource leak. We are deferring the fix for a bit to think about it. I was planning on surveying the code to try to identify areas like the one you mention before doing any surgery. (Plus I have to deal with statement cancel semantics to deal with another problem we have been seeing where transactions just get stuck because a transaction hangs. I'll post a description in JIRA shortly.) > 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
