jaybird
jaybird copied to clipboard
FirebirdSQL
Improve cursor close handling [JDBC573]
Submitted by: @mrotteveel
Is related to JDBC531 Is related to JDBC571
In JDBC571 we added some stopgap measures for CURSOR_OPEN state affecting reuse. We need to investigate if there is a better, more general solution possible. Part of the problem is that the driver relies (relied) on result set creation to properly close the statement cursor, while some code paths don't create a result set (or fail to create one, as addressed in JDBC571).
For example another codepath that causes this problem (which is corrected by the stopgap measure `ensureClosedCursor`) is executing a select with `Statement.execute(..)`, but never actually retrieving the result set with `getResultSet()`. Before the stopgap measure, this would leave the statement in CURSOR_OPEN state, disallowing reuse.
Modified by: @mrotteveel
description: In JDBC571 we added some stopgap measures for CURSOR_OPEN state affecting reuse. We need to investigate if there is a better, more general solution possible. Part of the problem is that the driver relies (relied) on result set creation to properly closer the statement cursor, while some code paths don't create a result set (or fail to create on, as addressed in JDBC571).
For example another codepath that causes this problem (which is corrected by the stopgap measure `ensureClosedCursor`) is executing a select with `Statement.execute(..)`, but never actually retrieving the result set with `getResultSet()`. Before the stopgap measure, this would leave the statement in CURSOR_OPEN state, disallowing reuse.
=>
In JDBC571 we added some stopgap measures for CURSOR_OPEN state affecting reuse. We need to investigate if there is a better, more general solution possible. Part of the problem is that the driver relies (relied) on result set creation to properly closer the statement cursor, while some code paths don't create a result set (or fail to create one, as addressed in JDBC571).
For example another codepath that causes this problem (which is corrected by the stopgap measure `ensureClosedCursor`) is executing a select with `Statement.execute(..)`, but never actually retrieving the result set with `getResultSet()`. Before the stopgap measure, this would leave the statement in CURSOR_OPEN state, disallowing reuse.
Modified by: @mrotteveel
description: In JDBC571 we added some stopgap measures for CURSOR_OPEN state affecting reuse. We need to investigate if there is a better, more general solution possible. Part of the problem is that the driver relies (relied) on result set creation to properly closer the statement cursor, while some code paths don't create a result set (or fail to create one, as addressed in JDBC571).
For example another codepath that causes this problem (which is corrected by the stopgap measure `ensureClosedCursor`) is executing a select with `Statement.execute(..)`, but never actually retrieving the result set with `getResultSet()`. Before the stopgap measure, this would leave the statement in CURSOR_OPEN state, disallowing reuse.
=>
In JDBC571 we added some stopgap measures for CURSOR_OPEN state affecting reuse. We need to investigate if there is a better, more general solution possible. Part of the problem is that the driver relies (relied) on result set creation to properly close the statement cursor, while some code paths don't create a result set (or fail to create one, as addressed in JDBC571).
For example another codepath that causes this problem (which is corrected by the stopgap measure `ensureClosedCursor`) is executing a select with `Statement.execute(..)`, but never actually retrieving the result set with `getResultSet()`. Before the stopgap measure, this would leave the statement in CURSOR_OPEN state, disallowing reuse.
Promoted the stopgap to the definitive solution, removing the debug logging.
