Improve cursor close handling [JDBC573]

[firebird-automations]

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.

[firebird-automations]

Modified by: @mrotteveel

Fix Version: Jaybird 5 [ 10871 ]

[firebird-automations]

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.

[firebird-automations]

Modified by: @mrotteveel

Link: This issue is related to JDBC531 [ JDBC531 ]

[firebird-automations]

Modified by: @mrotteveel

Link: This issue is related to JDBC571 [ JDBC571 ]

[firebird-automations]

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.

[mrotteveel]

Promoted the stopgap to the definitive solution, removing the debug logging.