db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sunitha Kambhampati (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1732) The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
Date Thu, 28 Sep 2006 14:54:51 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]

Sunitha Kambhampati updated DERBY-1732:

    Attachment: derby1732.diff.txt

On a JVM error, the cleanup at the store layer treats it as a session_severity error -- 
see RAMTransactionContext.cleanupOnError(), XactContext.cleanupOnError().
the transaction is aborted,destroyed, transaction context is pop'd from the context stack.

At the language side however:
GenericStatementContext (SC) will treat a java error to be similar to STATEMENT_SEVERITY.
GenericLanguageConnectionContex (LCC) will treat a java error to be of TRANSACTION_SEVERITY.

If an exception occurs, the contextManager.cleanupOnError is called to ensure corrective action
can be taken. The context manager will unwind the contexts during cleanup in the reverse order
they were placed in the global stack.  

In ContextManager.cleanupOnError(), 
-- A non StandardException (a jvm error) gets mapped to NO_APPLICABLE_SEVERITY here:
			int errorSeverity = error instanceof StandardException ?
				((StandardException) error).getSeverity() :

-- Next, we walk down the stack calling cleanup on each context as long as if we reached the
lastHandler or if we have reached end of stack. 

So if a given context is the last handler for an error of some severity, then we stop there
and do not call cleanup on the context's below it.

The derby1707 repro debugging shows that in this case  - at prepare time for the statement,
a NPE is thrown from GenericStatement.prepMinion. In the context stack,store contexts are
first cleaned up and then the SC cleanup is called. Note: LCC is below in the stack and LCC
cleanup does not get called since the SC.isLastHandler returns true.

-- isLastHandler for GenericStatement is not right. JVM errors severity gets mapped to NO_APPLICABLE_SEVERITY
ContextManager.cleanupOnError().  Thus on cleanup, for JVM error SC.isLastHandler can return
true for some cases(when rollbackParentContext is false, and inUse is true).  This is incorrect
because for JVM errors, it is necessary to let the outer contexts know and take necessary
corrective action.

This patch makes the following changes:
1. Make change to GenericStatementContext.isLastHandler() so it will return false for JVM
errors thus allowing the outer contexts to take corrective action.
2. Store transaction context treats JVM errors as session severity. To ensure consistency,
map severity for non StandardException instances to be SESSION_SEVERITY in GenericLanguageContext,
and GenericStatementContext. 

There is an existing DERBY-1528 which also results in a npe and then the raw store protocol
violation error. With this change, if you run the repro (repro1528_npe), instead of a raw
store protocol violation error, you will get a java.sql.SQLException 'No current exception'

Ran derbyall on ibm142/linux ok with 2 expected failures unrelated to this change. (NSInSameJVM
and blobclob4BLOB)

I have been using the derby1707 repro without the fix for this jira for testing purposes.
 Are there any suggestions on how best to add a test for this case. One way is to simulate
a java error using debug flags but I dont like that approach.  Suggestions welcome.  I can
make the yet-to-be-fixed derby1528 repro as a test,but that will no longer test this fix when
we eventually fix derby-1528.

Please take a look at this patch. I am new to this area, so would appreciate more eyes on
this patch.  Thanks.

> The language and store systems treat a JVM error such as OutOfMemoryError differently
leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-1732
>                 URL: http://issues.apache.org/jira/browse/DERBY-1732
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL, Store
>            Reporter: Daniel John Debrunner
>         Assigned To: Sunitha Kambhampati
>         Attachments: derby1732.diff.txt, derby1732.stat.txt
> Don't have the exact details, but remember noticing it a while ago. I think the store
transaction context closes the transaction on such an error, while the language conneciton
context just rollsback the transaction or the statement. I think the best and consistent approach
would be to close the connection.

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


View raw message