You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, V11Statement#free(int) will not flush the free packet, deferring it for later processing when something else is sent over the connection. This behaviour is similar to fbclient.dll. The downside of this is that, when you close a prepared statement (or 'unprepare' a statement) and then do nothing else with the connection for a long time, the statement will retain existence locks on metadata objects.
Flushing immediately for DSQL_drop and DSQL_unprepare (and maybe not for DSQL_close) has the advantage that the prepared statement and its existence locks are released immediately and not deferred until some later activity on the connection.
Submitted by: @mrotteveel
Is related to CORE6519
Currently, V11Statement#free(int) will not flush the free packet, deferring it for later processing when something else is sent over the connection. This behaviour is similar to fbclient.dll. The downside of this is that, when you close a prepared statement (or 'unprepare' a statement) and then do nothing else with the connection for a long time, the statement will retain existence locks on metadata objects.
Flushing immediately for DSQL_drop and DSQL_unprepare (and maybe not for DSQL_close) has the advantage that the prepared statement and its existence locks are released immediately and not deferred until some later activity on the connection.
Commits: 1b7767a 787d52b c61b876
The text was updated successfully, but these errors were encountered: