Thanks in advance.

I am prototyping a queueing system built around Firebird, similar in
core functionality to MQ series from IBM. My first series of
functional test cases may have exposed a bug, or possibly a side
effect of an optimization, in either the Firebird engine or (less
likely) the jaybird JDBC driver. I have not confirmed yet that it
happens in Super server, and I am fresh out of Windows installations
to test against.

The functional requirement being tested is that the system
administrator must be able to construct and destroy queues and their
backing storage (1 table + 1 generator) dynamically at runtime.

Architecturally, the queue system "owns" its own firebird database
instance, and connects to it using a connection pool of configurable size.

Queue users (including the administrator) connect to the queue system
via a sockets connection, and the queue system ties requests from the
connections to database connections in real time for the duration of
the operation. On commit, the firebird connection is released back to
the connection pool.

When a queue is constructed, the backing table and sequence generator
are constructed, and all 4 of the queries that address the backing
table and the 1 query that addresses the generator are prepared in all
connections.

When a queue is destroyed, the queries that addressed the backing
table and sequence generator are closed and (allegedly) disposed of,
and then the table and generator themselves are dropped.

The test case is simple.

1. Construct a connection pool of 2 connections

2. construct and destroy the same queue repeatedly - pseudocode follows:

for (int count=0;count<10;count++ {
executeConstructDDL ();
for each conection executePrepareDml();
commit ();

for each connection executeCloseDml();
executeDropDDL ();
commit;
}



On the second pass, the attempt to prepare the first query against the
second connection will fail with this message:

org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544343. invalid
request BLR at offset 64
table id 198 is not defined
<snip ... call stack >

Is this (a) a known constraint of FB (deliberate optimization), (b) a
new bug that needs to be reported, (c) an old bug that is resolved in
FB2, or (d) something that is a function of the jaybird JDBC connector
(which I would then need to report to the firebird-java list)?