> I think so. I don't think anyone who would respond appropriately to
> this message would ever get in the situation of closing a connection
> with an active transaction. Firebird can't access an unprepared
> transaction over more than one connection anyway, so if you use xa
> you have to have a connection manager that associates the connections
> with the transactions they are in. Closing a connection with an
> active transaction has to mean that something has gone horribly wrong
> and you have no way to recover, so rolling back any unprepared work
> is acceptable. If at some point in the future the wire protocol is
> improved so we can have tightly coupled branches and don't need
> transaction <> connection association in the connection manager, then
> we can stop rolling back unprepared work when a connection is closed.
>
> It might be reasonable to log a message but I no longer think its
> reasonable to fail to execute the users' request to close the
> connection.

Sounds ok, but I'm not yet convinced - I did not see this error message
until now. I will check the behavior of JNI layer to see whether it
closes socket or not. I guess we should be consistent with it (this also
applies to socket errors - have to check what error code is returned).

In this particular case I am curious why it happens at all. According to
the stack trace it happens when JBoss tries to recover some transaction.
We use a single connection and two transactions - one to fetch a txId
from the system table, and after that we attach the in-limbo transaction
to the connection and try to end it. As you say, something is going
horribly wrong, and what we're trying to do is rollback the prepared
transaction being recovered and commit the temp transaction used to
fetch the txId. Yes, we could ignore an error here, but then we will
loose a possibility to find an issue at all.

I will prepare a reworked version of the method, hopefully we will see
more error messages here.

Roman