[
http://issues.apache.org/jira/browse/DERBY-1020?page=comments#action_12414620 ]
Kathey Marsden commented on DERBY-1020:
---------------------------------------
PROBLEM ANALYSIS:
I think the source of the exception is in Database.close() in the rollback()
call:
if ((conn != null) && !conn.isClosed())
{
if (! forXA)
{
// The DERBY-1020 happens here on
rollback if the connection is no longer active
// The rollback is important in the
normal case because conn.close() will fail if there is
// an active transaction.
conn.rollback();
}
conn.close();
}
Currently any exception that occurs on rollback() or close() is ultimately
caught and logged by this code in DRDAConnThread.sessionClose()
} catch (SQLException se)
{
// If something went wrong closing down the session.
// Print an error to the console and close this
//thread. (6013)
sendUnexpectedException(se);
close();
}
The problem is that after an intentional shutdown, the error on rollback() is
not unexpected at all so it should never get to the catch block.
Does that sound like a correct analysis?
EXCEPTION SCENARIOS:
If an exception happens on rollback() or close() there are basically three
scenarios
1) The connection is still active and there was some unexpected exception
rolling back or closing the connection.
This needs to be logged because it might lead to locks being held until
the connection is garbage collected
Not logging the failure would make tracking such a problem down very
difficult.
2) The connection is no longer active because of intentional shutdown. (e.g.
the database has been shutdown like in 1020)
This kind of exception, I think, can be safely ignored.
3) The connection is no longer active because of some unexpected event like a
crash. There has been some debate in the past whether this type of exception
needs to be logged. I thought session level exceptions in this block of code
could safely be ignored since the fact that they were session severity meant
the session was shutdown. Tomohito thought it was not good to ignore them and
I understand that point.
SOLUTION OPTIONS:
My thought was that we could remove the rollback and the associated exception
by having a close() method that would force a rollback and close, something
like:
if ((conn != null) && !conn.isClosed())
{
// force the connection to rollback and close
instead of throwing an error if we are in an active xact
conn.forceClose();
}
Brian suggested
|It seems like it would be cleaner just to
|teach the engine not to throw an exception in this case.
That sounds good, but what call do we teach?
I think Connection.rollback() still should throw an exception if the database
is shutdown so we wouldn't teach rollback(). Perhaps Connection.isClosed()
could return true if the database has been shutdown intentionally. That way we
would never enter the code block causing the exception.
> Network Server treats errors on cleanup of connections as an unexpected error
> after intentional shutdown of the database/server
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1020
> URL: http://issues.apache.org/jira/browse/DERBY-1020
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.2.0.0, 10.1.3.0, 10.1.2.3, 10.3.0.0
> Reporter: Kathey Marsden
> Priority: Minor
>
> Any exceptions that occur in the rollback and close of connections in
> Session.close() are treated as unexpected errors and print to the console.
> Exceptions that occur cleaning up the connection after intentional shutdown
> are not really unexpected.
> The console message can be disconcerting and intermittent as it depends on
> time. It is the root cause of DERBY-273 and I believe DERBY-803
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
