Hi Nickolay,

> There is locking. When engine does internal DDL queries it does
> more locking in isc_tpb_consistency mode. Existance of prepared
> statement on one connection prevents any DDL modification of any
> object it uses even on this connection - this is by design. If
> there is some kind of resource leak when statement doesn't get
> closed nobody will be able to do any DDL on objects it uses until
> you restart the server.

Ok, but if there is no resource leak, then it should be ok. Right? I
mean, in theory, if we execute statement, it succeeds, and we close
the statement correctly, lock is released, right?

> > If statements are executed each in its own connection (like get
> > connection from the pool, execute statement, return connection to
> > the pool), such problem cleanly points out on the bug in either
> > pool implementation, or our transaction management. That is why I
> > asked for the code that causes this bug.
>
> This code would be very helpful. But conditions when it occurs may
> point to isc_tpb_consistency mode problems (buggy code works in
> other tools, server was cleanly restarted before trying it in
> Jaybird, etc). I tested DDL a lot in isc_tpb_concurrency mode using
> FB1 and Jaybird and it makes almost no problems if you restart
> server often enough (usually every 30-50 DDL statements) and use
> only one connection.

I think we need to include some test case that checks if there are
resource leaks in different cases. JDBC specs are pretty clear about
what should be closed when, and closing the connection (even if done
in finalize() method, not yet implemented though) should close all
statements it prepared. I'm almost 100% sure that we are not clean
here... :(

So, I will try to write such test case. This issue _must_ be checked
before 1.0 is released. I created a bug report and assigned it to
myself, so we do not forget about it.

Thanks!
Roman Rokytskyy