[ https://forge.continuent.org/jira/browse/SEQUOIA-1003?page=all ]
Robert Hodges resolved SEQUOIA-1003:
------------------------------------
Resolution: Fixed
Implement connection management for ControllerResultSet instances, which now
holds onto the connection until back end results are completely fetched out of
the result set. This fix does not deal with issues that may arise when reads
are forwarded to another controller in failover scenarios. However, those
scenarios already do not appear to work correctly when using fetch size hints
so this fix does not seem to risk making things worse.
Failover scenarios should be investigated and handled in a separate JIRA.
> 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.11
>
>
> 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
