On 20-03-2021 09:54, Vlad Khorsun wrote:
06.03.2021 20:50, Mark Rotteveel wrote:
Freeing the statement with DSQL_close, DSQL_drop or DSQL_unprepare is
deferred (since the v11 protocol). As a result, the free is only sent
when something else is subsequently sent over the connection.
Yes, and usually it is op_commit.
Your assumption about this doesn't always hold. For example, when you
use isc_tpb_autocommit and don't use an explicit commit at that point,
or when the commit occurs before the statement close, which happens in
Jaybird in its default auto-commit mode, and is not unlikely to occur in
normal Java code with explicit commits.
For example
// ... obtain connection
connection.setAutoCommit(false);
// ...
try (var preparedStatement pstmt = connection.prepareStatement(
"update sometable sometable set x = 5 where y = ?")) {
pstmt.setInt(1, 7);
pstmt.executeUpdate();
// commit happens here
connection.commit();
} // statement close happens here!
I wonder if this makes sense for DSQL_drop and DSQL_unprepare, because
the end result is that if you free the statement and then leave it
alone for a long time, the statement remains prepared and holding
existence locks, which can cause issues if you execute DDL dropping or
modifying those metadata objects using another connection.
I think that sending the free immediately (at least for DSQL_drop and
DSQL_unprepare), and only deferring the processing of the response
might make more sense.
What do you think?
I don't think it makes much sence as there are a lot of other ways to
hold metadata locks.
The problem I observed is that due to close of the statement you expect
the lock to be released, but in fact it is not because the close has not
yet been sent to the server. This makes troubleshooting this type of
problem harder than necessary. When I stumbled across it two weeks ago
when testing Hibernate, I was first hunting for statement leaks in the
Java code of both Hibernate and Jaybird.
I have since fixed this in Jaybird's wire protocol implementation (which
did a similar thing as fbclient), but the problem remains when using
native. In a strange coincidence, yesterday someone reported the exact
same problem: https://groups.google.com/g/firebird-java/c/DuIRTYJru7U
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel