[
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
