On 22-12-2016 09:57, hugo.larson@... [Firebird-Java] wrote:

> Let me put you in the picture of what Borland JBuilder DataExpress is.
> The library basically revolves around two classes: DataBase and
> QueryDataSet.
> DataBase is like a wrapper on jdbc Connection class and QueryDataSet is
> a holder of data fetched. Like CachedRowSet but much richer.
> A QueryDataSet object is a holder of a SQL statement with parameters and
> is executed and populated with a DataBase Object.
>
> You asked about setPool(..). I have a simple connection pool mechanism
> is based on BlockingQueue where I set the JDBC connection in the wrapper
> class DataBase. The exception is thrown when jdbc
> connection.getAutoCommit() is called in DataBase class in this
> particular exception.

Could you also send me the code of the connection pool mechanism, so I
can see what it does?

> The exceptions seems to be thrown when a FBResultSetMetaData is used?

The "You cannot getAutoCommit on an unassociated closed connection." is
thrown after the call to `setJdbcConnection` by
`advit.web.dxweb.MyQueryDataSet.setPoolconn`, which suggests it is
setting an already closed connection on `DataBase`.

The NPE occurs when the `ResultSetMetaData` is accessed.

> It seems to be provoked when used from multiple threads. Maybe something in
> FBResultSetMetaData is shared and not not thread safe?
> I'm assuming that each jdbc connection object is independent and thread
> safe?

Well, Jaybird is theoretically thread-safe (although there could be bugs
lurking), however using a connection from multiple threads in parallel
is just not a good idea, because although each individual method calls
would be thread-safe, it can still break things. As an example consider
one thread calling `commit` on the connection, while another thread is
iterating over a result set on that same connection: the commit will
close the result set which will happen perfectly thread safe, it is
still not what the other thread expects to happen.

However in this specific case a new instance of `FBResultSetMetaData` is
created, and the thing that is shared is the connection.

> I never close a connection. The only place a connection is close is in
> the DataBase class finalize method. Furthermore if I explicitly close a
> connection the DataBase class reopens it automatically.

Well, Jaybird connections cannot be reopened, so I assume you mean that
DataBase will open a new connection.

In certain error conditions that indicate unrecoverable, connection
breaking errors, Jaybird itself will (try to) destroy the managed
connection used by the JDBC connection (specifically for
isc_network_error (335544721), isc_io_error (335544344), isc_req_sync
(335544364). But the specific example of the result set metadata would
actually result in exception: org.firebirdsql.jdbc.FBSQLException: GDS
Exception. 335544363. no transaction for request.

Looking at the JCA parts of Jaybird does give me the impression that are
too many moving parts and things happening at too many different levels
that might result in conflicting behavior. I might just consider
throwing away the current JDBC and JCA implementation and start over in
Jaybird 4... (similar to what I did with the low-level implementation in
Jaybird 3).

Mark
--
Mark Rotteveel