db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1020) Network Server treats errors on cleanup of connections as an unexpected error after intentional shutdown of the database/server
Date Sun, 04 Jun 2006 03:59:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1020?page=comments#action_12414620 ] 

Kathey Marsden commented on DERBY-1020:


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.

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)

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?


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.


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

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

> 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:,,,
>     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
> 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:
For more information on JIRA, see:

View raw message