db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (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 Mon, 05 Jun 2006 17:19:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1020?page=comments#action_12414793 ] 

Bryan Pendleton commented on DERBY-1020:
----------------------------------------

Kathey said:

> // force the connection to rollback and close instead of throwing an error if we are
in an active xact 
> conn.forceClose();

I think that the forceClose() method that you are proposing is very similar to the idea
I was trying to suggest about how rollback() could behave in this case.

I thought the DERBY-273 stack traces are kind of interesting. Here's a snip from one of those
traces:

org.apache.derby.iapi.services.context.ShutdownException:
at org.apache.derby.iapi.services.context.ContextManager.checkInterrupt(ContextManager.java:374)
at org.apache.derby.iapi.services.context.ContextManager.popContext(ContextManager.java:152)
at org.apache.derby.iapi.services.context.ContextImpl.popMe(ContextImpl.java:80)
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.resetSavepoints(GenericLanguageConnectionContext.java:1309)
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(GenericLanguageConnectionContext.java:1288)

What I find interesting about this is that at the point where doRollback() calls resetSavepoints(),
the rollback is actually fully complete. We are at the point where the rollback code is doing:

  // reset the savepoints to the new
  // location, since any outer nesting
  // levels expet there to be a savepoint
  resetSavepoints(statementContext);

That is, we have finished the rollback of this transaction, and now we are setting
up savepoints in order to begin *the next transaction*.

Well, there isn't going to be any next transaction. The session has disconnected,
and we are just trying to clean it up before we discard it. We don't want the engine
to set up a next transaction. We just want it to roll the current transaction back and then
return to us so we can close up shop and go home.

So it seems to me that if we just changed the very end of 
GenericLanguageConnectionContext.doRollback() so that
the call to resetSavepoints() was conditional on whether or not the database
had been shutdown, then rollback() would already have the semantics that you
desire from the forceClose() method.

In pseudo-code, something like:

  if (databaseIsOpen)
      resetSavepoints();
  else
      this.close(); // nothing more can be done with this connection




> 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


Mime
View raw message