Subject Re: [Firebird-Java] reuse of connection after failure.
Author David Jencks
On Mar 14, 2007, at 7:51 PM, Roman Rokytskyy wrote:

> > I'm having a lot of trouble remembering why we won't let anyone
> close
> > a connection with an active transaction. At the moment it seems to
> > me that if the tx has not been prepared we should roll it back and
> > close the connection, otherwise just close it and the tx will be in
> > limbo.
> >
> > Can anyone remember why we made the decision we did? I think it made
> > sense at the time :-)
> Look at the stack trace:
> Caused by: org.firebirdsql.gds.GDSException: cannot disconnect
> database
> with open transactions (1 active)
> at
> org.firebirdsql.gds.impl.wire.AbstractJavaGDSImpl.readStatusVector
> (
> at
> org.firebirdsql.gds.impl.wire.AbstractJavaGDSImpl.receiveResponse
> (
> at
> org.firebirdsql.gds.impl.wire.AbstractJavaGDSImpl.iscDetachDatabase
> (
> We had such code before, but I have eliminated it long time ago. So
> now,
> it looks like it is Firebird who complains.
> The question is - should we close socket anyway?
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

What do you think?

david jencks

> Roman