Submitted by: @mrotteveel
Relate to JDBC638
Since the v11 protocol, fbclient will defer sending the free packet for op_free_statement until other activity on the connection. This approach can lead to issues when there is no further activity on the connection for a while, because the statement is not unprepared or dropped server-side, leading to Firebird holding on the metadata object locks for longer than necessary, which for example can prevent subsequent DDL on another connection to succeed. This can cause either transactions waiting for the lock to be released or errors like "unsuccessful metadata update; object TABLE "TEST" is in use [SQLState:42000, ISC error code:335544351]"
I propose that for DSQL_drop and DSQL_unprepare, the free packet is sent immediately, but processing of the response is deferred until later. For DSQL_close the current behaviour is not very problematic, so could remain as is. On firebird-devel, Vlad suggested an alternative approach to use a timer to send deferred packets with a delay so that multiple subsequent closes can be sent together.
See also JDBC638 and https://groups.google.com/g/firebird-java/c/DuIRTYJru7U/m/cxxv49RGAgAJ and the discussion on firebird-devel titled "Does deferred processing of DSQL_drop and DSQL_unprepare make sense?"
Submitted by: @mrotteveel
Relate to JDBC638
Since the v11 protocol, fbclient will defer sending the free packet for op_free_statement until other activity on the connection. This approach can lead to issues when there is no further activity on the connection for a while, because the statement is not unprepared or dropped server-side, leading to Firebird holding on the metadata object locks for longer than necessary, which for example can prevent subsequent DDL on another connection to succeed. This can cause either transactions waiting for the lock to be released or errors like "unsuccessful metadata update; object TABLE "TEST" is in use [SQLState:42000, ISC error code:335544351]"
I propose that for DSQL_drop and DSQL_unprepare, the free packet is sent immediately, but processing of the response is deferred until later. For DSQL_close the current behaviour is not very problematic, so could remain as is. On firebird-devel, Vlad suggested an alternative approach to use a timer to send deferred packets with a delay so that multiple subsequent closes can be sent together.
See also JDBC638 and https://groups.google.com/g/firebird-java/c/DuIRTYJru7U/m/cxxv49RGAgAJ and the discussion on firebird-devel titled "Does deferred processing of DSQL_drop and DSQL_unprepare make sense?"