Hi Josef,

> With changing number 1 (see below) we shouldn't get the NPE anymore.
> Because of throwing the GDSException the DB-Handle is going to be
> destroyed. One record is lost but subsequent records are written
> again (witout the change, the erroneous situation lasts for hours).

What do you mean that a record is lost? How can it be lost if it was never
inserted (your GDSException should result in SQLException on the application
level)?

> On the other hand we like to know your opinion wether this could be
> a temporarily solution.

As I understand, there is following situation:

a) application starts the transaction and starts to insert rows;

b) at some point server reports the "fatal" error and db connection is
destroyed.

c) application tries to continue, but the db_handle.out is no longer valid.

In Fix 1. you throw an exception in this case. In Fix. 2 and 3 you try to
reconnect silently.

From my point of view, correct is Fix 1 (though the place is not very
correct), since the transaction was rolled back by server automatically when
the connection to server is destroyed. I cannot comment cases 2. and 3...

In fact, when doing b) driver should mark all transactions handles to that
connection as invalid (that can be done in invalidate() method of the
isc_db_handle_impl - it has a list of active transaction handles). After
that FBConnectionManager for each operation should check whether tr_handle
is valid and throw an exception if it's not. FBConnectionManager is allowed
to get completely new db handle and tr handle only when it is in
startTransaction method. In all other cases it should report an error.

But that's all are just my ideas. The code was written by David Jencks,
hopefully he reads this email and answers it more professionally.

Roman