You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Tim Dudgeon <td...@informaticsmatters.com> on 2014/08/29 17:17:10 UTC
NPE from InternalTriggerExecutionContext.cleanup()
Using Derby 10.10.1.1 I'm seeing strange behaviour when doing a series
of inserts that have triggers associated.
About 2000 rows get inserted fine, then it blows up completely.
The derby.log file contains stuff like this:
Database Class Loader started -
derby.database.classpath='APP.ExtraFunctions'
Loaded chemaxon.misc.derby.functions.MiniregFunctions from database jar
"APP"."EXTRAFUNCTIONS"
Fri Aug 29 15:37:56 BST 2014 Thread[Default RequestProcessor,1,system]
(XID = 448992), (SESSIONID = 1), (DATABASE =
C:\Users\timbo\Documents\IJCProjects\mini-regs\Vanilla
Oracle/.config/derby-minireg-11-jun/db), (DRDAID = null), Cleanup action
starting
Fri Aug 29 15:37:56 BST 2014 Thread[Default RequestProcessor,1,system]
(XID = 448992), (SESSIONID = 1), (DATABASE = C:\Users\ ... ), (DRDAID =
null), Failed Statement is: INSERT INTO APP.COMPOUNDS ( ... ) VALUES
(?,?,?,?,?,?,?,CURRENT_TIMESTAMP,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
with 31 parameters begin parameter #1: BLOB:Length=1658 :end ...
java.lang.NullPointerException
at
org.apache.derby.impl.sql.execute.InternalTriggerExecutionContext.cleanup(Unknown
Source)
at
org.apache.derby.impl.sql.execute.TriggerEventActivator.cleanup(Unknown
Source)
at org.apache.derby.impl.sql.execute.InsertResultSet.cleanUp(Unknown
Source)
at
org.apache.derby.impl.sql.conn.GenericStatementContext.cleanupOnError(Unknown
Source)
at
org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown
Source)
...
(somethings cut out for brevity)
The trigger involved uses a custom java function that's been added to
the DB, so the real problem might well be there, but the stack trace
doesn't give much of a pointer.
Any suggestions for where to look?
Tim
Re: NPE from InternalTriggerExecutionContext.cleanup()
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Tim Dudgeon <td...@informaticsmatters.com> writes:
> On 03/09/2014 13:21, Knut Anders Hatlen wrote:
>> I don't think so. Derby doesn't allow UPDATE statements in BEFORE
>> triggers
>
> I was meaning to just set the column value from the sequence into the
> new values, not using an insert statement. In my Oracle version its
> like this:
> CREATE OR REPLACE TRIGGER samples_code_trg BEFORE INSERT ON samples
> FOR EACH ROW
> BEGIN
> SELECT TO_CHAR(seq_sample_code.nextval) INTO :NEW.sample_code FROM
> dual; END;
>
> I've never had much joy with BEFORE INSERT triggers on Derby.
Derby doesn't allow you to change the new values in triggers, I'm
afraid. As you've noticed, there's not a whole lot you can do with
BEFORE triggers in Derby...
--
Knut Anders
Re: NPE from InternalTriggerExecutionContext.cleanup()
Posted by Tim Dudgeon <td...@informaticsmatters.com>.
On 03/09/2014 13:21, Knut Anders Hatlen wrote:
> I don't think so. Derby doesn't allow UPDATE statements in BEFORE
> triggers
I was meaning to just set the column value from the sequence into the
new values, not using an insert statement. In my Oracle version its like
this:
CREATE OR REPLACE TRIGGER samples_code_trg BEFORE INSERT ON samples
FOR EACH ROW
BEGIN
SELECT TO_CHAR(seq_sample_code.nextval) INTO :NEW.sample_code FROM
dual; END;
I've never had much joy with BEFORE INSERT triggers on Derby.
Thanks
Tim
Re: NPE from InternalTriggerExecutionContext.cleanup()
Posted by Tim Dudgeon <td...@informaticsmatters.com>.
On 03/09/2014 13:21, Knut Anders Hatlen wrote:
> Is there also a trigger that is "AFTER UPDATE ON samples"? From the
> stack trace, it looks like the error happens when an INSERT statement
> triggers an UPDATE that again causes some other AFTER trigger to fire.
Yes there is so you're probably on the right track
>
>> >Unfortunately I'm unable to turn this into a simple reproducible test case.
> Is it reproducible in your environment? If so, there might be more clues
> (at least line numbers in the stack trace) if you run with debug-enabled
> jar files. They're available from the download page, look for the
> downloads named *-lib-debug.zip or *-lib-debug.tar.gz.
>
> It might be worth a bug report even if you don't have a simple
> reproducible test case, so that we have a place to collect information
> about the bug.
Unfortunately I rebuilt all the tables and triggers and am now not
seeing this any more.
I added it to JIRA with the stacktrace:
https://issues.apache.org/jira/browse/DERBY-6726
Tim
Re: NPE from InternalTriggerExecutionContext.cleanup()
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Tim Dudgeon <td...@informaticsmatters.com> writes:
> On 02/09/2014 13:37, Knut Anders Hatlen wrote:
>> Tim Dudgeon <td...@informaticsmatters.com> writes:
>>
>>> No joy. Seems like nothing extra is being logged.
>>
>> From the stack trace, cleanupOnError() seems to be called from this
>> catch block in GenericPreparedStatement.executeStatement():
>>
>> } catch (StandardException se) {
>> /* Cann't handle recompiling SPS action recompile here */
>> if (!se.getMessageId().equals(SQLState.LANG_STATEMENT_NEEDS_RECOMPILE)
>> || spsAction)
>> throw se;
>> statementContext.cleanupOnError(se);
>> continue recompileOutOfDatePlan;
>>
>> }
>>
>> It looks like the INSERT statement got a recompilation request. That's
>> not really an error, but an exception is raised to signal the condition
>> internally. The statement is supposed to be recompiled and retried
>> automatically after cleaning up the execution state. Unfortunately, the
>> trigger execution context doesn't seem to be prepared for this scenario,
>> and it fails with a NullPointerException in cleanup().
>>
>> I've managed to reproduce the NPE in my environment, and I've filed
>> https://issues.apache.org/jira/browse/DERBY-6724 to track the issue.
>>
>> Thanks,
>>
>>
>
> Interestingly I'm seeing a similar (but not identical) error with
> another trigger. This time the stack trace is this:
>
> Tue Sep 02 13:39:09 BST 2014 Thread[SQLExecution,1,system] (XID =
> 62693), (SESSIONID = 1), (DATABASE =
> C:/Users/timbo/Documents/IJCProjects/mini-regs/Vanilla
> Oracle/.config/derby-minireg-01-sep/db), (DRDAID = null), Failed
> Statement is: UPDATE samples SET sample_code = 'S123456' WHERE
> sample_id = CAST
> (org.apache.derby.iapi.db.Factory::getTriggerExecutionContext().getNewRow().getObject(1)
> AS INTEGER)
> java.lang.NullPointerException
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTriggerActionString(Unknown
> Source)
> at
> org.apache.derby.iapi.sql.dictionary.TriggerDescriptor.getActionSPS(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.GenericTriggerExecutor.getAction(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTriggers(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
> Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeSubStatement(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
> Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
>
>
> The trigger definition is this:
>
> CREATE TRIGGER samples_code_trg
> AFTER INSERT ON samples
> REFERENCING NEW AS newrow FOR EACH ROW MODE DB2SQL
> UPDATE samples SET sample_code = 'S123456'
> WHERE samples.sample_id = newrow.sample_id;
Is there also a trigger that is "AFTER UPDATE ON samples"? From the
stack trace, it looks like the error happens when an INSERT statement
triggers an UPDATE that again causes some other AFTER trigger to fire.
> Unfortunately I'm unable to turn this into a simple reproducible test case.
Is it reproducible in your environment? If so, there might be more clues
(at least line numbers in the stack trace) if you run with debug-enabled
jar files. They're available from the download page, look for the
downloads named *-lib-debug.zip or *-lib-debug.tar.gz.
It might be worth a bug report even if you don't have a simple
reproducible test case, so that we have a place to collect information
about the bug.
> This is with Derby 10.10.1.1
Some trigger bugs were found and fixed in 10.11 during the work on
DERBY-534 (WHEN clause in triggers). Most of them were backported and
included in the 10.10.2.0 release. I don't recall any bugs with the
stack trace you're seeing, though.
> On a related front, is it possible to do this with BEFORE INSERT
> trigger (the actual value for sample_code needs to come from a
> sequence - the value 'S123456' is just there to simplify things)?
I don't think so. Derby doesn't allow UPDATE statements in BEFORE
triggers.
--
Knut Anders
Re: NPE from InternalTriggerExecutionContext.cleanup()
Posted by Tim Dudgeon <td...@informaticsmatters.com>.
On 02/09/2014 13:37, Knut Anders Hatlen wrote:
> Tim Dudgeon <td...@informaticsmatters.com> writes:
>
>> No joy. Seems like nothing extra is being logged.
>
> From the stack trace, cleanupOnError() seems to be called from this
> catch block in GenericPreparedStatement.executeStatement():
>
> } catch (StandardException se) {
> /* Cann't handle recompiling SPS action recompile here */
> if (!se.getMessageId().equals(SQLState.LANG_STATEMENT_NEEDS_RECOMPILE)
> || spsAction)
> throw se;
> statementContext.cleanupOnError(se);
> continue recompileOutOfDatePlan;
>
> }
>
> It looks like the INSERT statement got a recompilation request. That's
> not really an error, but an exception is raised to signal the condition
> internally. The statement is supposed to be recompiled and retried
> automatically after cleaning up the execution state. Unfortunately, the
> trigger execution context doesn't seem to be prepared for this scenario,
> and it fails with a NullPointerException in cleanup().
>
> I've managed to reproduce the NPE in my environment, and I've filed
> https://issues.apache.org/jira/browse/DERBY-6724 to track the issue.
>
> Thanks,
>
>
Interestingly I'm seeing a similar (but not identical) error with
another trigger. This time the stack trace is this:
Tue Sep 02 13:39:09 BST 2014 Thread[SQLExecution,1,system] (XID =
62693), (SESSIONID = 1), (DATABASE =
C:/Users/timbo/Documents/IJCProjects/mini-regs/Vanilla
Oracle/.config/derby-minireg-01-sep/db), (DRDAID = null), Failed
Statement is: UPDATE samples SET sample_code = 'S123456' WHERE sample_id
= CAST
(org.apache.derby.iapi.db.Factory::getTriggerExecutionContext().getNewRow().getObject(1)
AS INTEGER)
java.lang.NullPointerException
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTriggerActionString(Unknown
Source)
at
org.apache.derby.iapi.sql.dictionary.TriggerDescriptor.getActionSPS(Unknown
Source)
at
org.apache.derby.impl.sql.execute.GenericTriggerExecutor.getAction(Unknown
Source)
at
org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown
Source)
at
org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown
Source)
at
org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTriggers(Unknown
Source)
at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source)
at
org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
Source)
at
org.apache.derby.impl.sql.GenericPreparedStatement.executeSubStatement(Unknown
Source)
at
org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown
Source)
at
org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown
Source)
at
org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown
Source)
at
org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown
Source)
at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source)
at
org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
The trigger definition is this:
CREATE TRIGGER samples_code_trg
AFTER INSERT ON samples
REFERENCING NEW AS newrow FOR EACH ROW MODE DB2SQL
UPDATE samples SET sample_code = 'S123456'
WHERE samples.sample_id = newrow.sample_id;
Unfortunately I'm unable to turn this into a simple reproducible test case.
This is with Derby 10.10.1.1
On a related front, is it possible to do this with BEFORE INSERT trigger
(the actual value for sample_code needs to come from a sequence - the
value 'S123456' is just there to simplify things)?
Tim
Re: NPE from InternalTriggerExecutionContext.cleanup()
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Tim Dudgeon <td...@informaticsmatters.com> writes:
> No joy. Seems like nothing extra is being logged.
>From the stack trace, cleanupOnError() seems to be called from this
catch block in GenericPreparedStatement.executeStatement():
} catch (StandardException se) {
/* Cann't handle recompiling SPS action recompile here */
if (!se.getMessageId().equals(SQLState.LANG_STATEMENT_NEEDS_RECOMPILE)
|| spsAction)
throw se;
statementContext.cleanupOnError(se);
continue recompileOutOfDatePlan;
}
It looks like the INSERT statement got a recompilation request. That's
not really an error, but an exception is raised to signal the condition
internally. The statement is supposed to be recompiled and retried
automatically after cleaning up the execution state. Unfortunately, the
trigger execution context doesn't seem to be prepared for this scenario,
and it fails with a NullPointerException in cleanup().
I've managed to reproduce the NPE in my environment, and I've filed
https://issues.apache.org/jira/browse/DERBY-6724 to track the issue.
Thanks,
--
Knut Anders
Re: NPE from InternalTriggerExecutionContext.cleanup()
Posted by Tim Dudgeon <td...@informaticsmatters.com>.
No joy. Seems like nothing extra is being logged.
Tim
On 01/09/2014 10:17, Knut Anders Hatlen wrote:
> Tim Dudgeon <td...@informaticsmatters.com> writes:
>
>> Thanks for the response.
>> So its seems I'm probably right that my trigger is the ultimate cause.
>> Any ideas on how to work out what is failing here as the real culprit
>> seem to being masked.
>
> Hi Tim,
>
> If you set the system property derby.stream.error.logSeverityLevel=0, so
> that all errors are written to derby.log, you may get some more
> information. Hopefully the original error is printed before the NPE is
> raised.
>
>> Tim
>>
>> On 29/08/2014 18:20, Rick Hillegas wrote:
>>> On 8/29/14 8:17 AM, Tim Dudgeon wrote:
>>>> Using Derby 10.10.1.1 I'm seeing strange behaviour when doing a series
>>>> of inserts that have triggers associated.
>>>> About 2000 rows get inserted fine, then it blows up completely.
>>>> The derby.log file contains stuff like this:
>>>>
>>>> Database Class Loader started -
>>>> derby.database.classpath='APP.ExtraFunctions'
>>>> Loaded chemaxon.misc.derby.functions.MiniregFunctions from database
>>>> jar "APP"."EXTRAFUNCTIONS"
>>>> Fri Aug 29 15:37:56 BST 2014 Thread[Default RequestProcessor,1,system]
>>>> (XID = 448992), (SESSIONID = 1), (DATABASE =
>>>> C:\Users\timbo\Documents\IJCProjects\mini-regs\Vanilla
>>>> Oracle/.config/derby-minireg-11-jun/db), (DRDAID = null), Cleanup
>>>> action starting
>>>> Fri Aug 29 15:37:56 BST 2014 Thread[Default RequestProcessor,1,system]
>>>> (XID = 448992), (SESSIONID = 1), (DATABASE = C:\Users\ ... ), (DRDAID
>>>> = null), Failed Statement is: INSERT INTO APP.COMPOUNDS ( ... ) VALUES
>>>> (?,?,?,?,?,?,?,CURRENT_TIMESTAMP,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
>>>> with 31 parameters begin parameter #1: BLOB:Length=1658 :end ...
>>>> java.lang.NullPointerException
>>>> at
>>>> org.apache.derby.impl.sql.execute.InternalTriggerExecutionContext.cleanup(Unknown
>>>> Source)
>>>> at
>>>> org.apache.derby.impl.sql.execute.TriggerEventActivator.cleanup(Unknown Source)
>>>>
>>>> at
>>>> org.apache.derby.impl.sql.execute.InsertResultSet.cleanUp(Unknown Source)
>>>> at
>>>> org.apache.derby.impl.sql.conn.GenericStatementContext.cleanupOnError(Unknown
>>>> Source)
>>>> at
>>>> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
>>>> Source)
>>>> at
>>>> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
>>>> Source)
>>>> at
>>>> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
>>>> Source)
>>>> at
>>>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
>>>> Source)
>>>> at
>>>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(Unknown
>>>> Source)
>>>> at
>>>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source)
>>>>
>>>> ...
>>>>
>>>> (somethings cut out for brevity)
>>>>
>>>>
>>>> The trigger involved uses a custom java function that's been added to
>>>> the DB, so the real problem might well be there, but the stack trace
>>>> doesn't give much of a pointer.
>>>>
>>>> Any suggestions for where to look?
>>>>
>>>> Tim
>>>>
>>>>
>>>>
>>> Hi Tim,
>>>
>>> This looks like a weakness in GenericStatementContext.cleanupOnError().
>>> The header comment for that method indicates that some more work needs
>>> to be done to protect the method when it trips across subsequent errors
>>> during statement cleanup. I have filed
>>> https://issues.apache.org/jira/browse/DERBY-6722 to track this defect.
>>>
>>> If I were tracking this down, I would instrument that method to make it
>>> print out the initial error before it calls topResultSet.cleanUp().
>>>
>>> Thanks for bringing this weakness to our attention...
>>> -Rick
>>>
>
Re: NPE from InternalTriggerExecutionContext.cleanup()
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Tim Dudgeon <td...@informaticsmatters.com> writes:
> Thanks for the response.
> So its seems I'm probably right that my trigger is the ultimate cause.
> Any ideas on how to work out what is failing here as the real culprit
> seem to being masked.
Hi Tim,
If you set the system property derby.stream.error.logSeverityLevel=0, so
that all errors are written to derby.log, you may get some more
information. Hopefully the original error is printed before the NPE is
raised.
> Tim
>
> On 29/08/2014 18:20, Rick Hillegas wrote:
>> On 8/29/14 8:17 AM, Tim Dudgeon wrote:
>>> Using Derby 10.10.1.1 I'm seeing strange behaviour when doing a series
>>> of inserts that have triggers associated.
>>> About 2000 rows get inserted fine, then it blows up completely.
>>> The derby.log file contains stuff like this:
>>>
>>> Database Class Loader started -
>>> derby.database.classpath='APP.ExtraFunctions'
>>> Loaded chemaxon.misc.derby.functions.MiniregFunctions from database
>>> jar "APP"."EXTRAFUNCTIONS"
>>> Fri Aug 29 15:37:56 BST 2014 Thread[Default RequestProcessor,1,system]
>>> (XID = 448992), (SESSIONID = 1), (DATABASE =
>>> C:\Users\timbo\Documents\IJCProjects\mini-regs\Vanilla
>>> Oracle/.config/derby-minireg-11-jun/db), (DRDAID = null), Cleanup
>>> action starting
>>> Fri Aug 29 15:37:56 BST 2014 Thread[Default RequestProcessor,1,system]
>>> (XID = 448992), (SESSIONID = 1), (DATABASE = C:\Users\ ... ), (DRDAID
>>> = null), Failed Statement is: INSERT INTO APP.COMPOUNDS ( ... ) VALUES
>>> (?,?,?,?,?,?,?,CURRENT_TIMESTAMP,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
>>> with 31 parameters begin parameter #1: BLOB:Length=1658 :end ...
>>> java.lang.NullPointerException
>>> at
>>> org.apache.derby.impl.sql.execute.InternalTriggerExecutionContext.cleanup(Unknown
>>> Source)
>>> at
>>> org.apache.derby.impl.sql.execute.TriggerEventActivator.cleanup(Unknown Source)
>>>
>>> at
>>> org.apache.derby.impl.sql.execute.InsertResultSet.cleanUp(Unknown Source)
>>> at
>>> org.apache.derby.impl.sql.conn.GenericStatementContext.cleanupOnError(Unknown
>>> Source)
>>> at
>>> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
>>> Source)
>>> at
>>> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
>>> Source)
>>> at
>>> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
>>> Source)
>>> at
>>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
>>> Source)
>>> at
>>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(Unknown
>>> Source)
>>> at
>>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source)
>>>
>>> ...
>>>
>>> (somethings cut out for brevity)
>>>
>>>
>>> The trigger involved uses a custom java function that's been added to
>>> the DB, so the real problem might well be there, but the stack trace
>>> doesn't give much of a pointer.
>>>
>>> Any suggestions for where to look?
>>>
>>> Tim
>>>
>>>
>>>
>> Hi Tim,
>>
>> This looks like a weakness in GenericStatementContext.cleanupOnError().
>> The header comment for that method indicates that some more work needs
>> to be done to protect the method when it trips across subsequent errors
>> during statement cleanup. I have filed
>> https://issues.apache.org/jira/browse/DERBY-6722 to track this defect.
>>
>> If I were tracking this down, I would instrument that method to make it
>> print out the initial error before it calls topResultSet.cleanUp().
>>
>> Thanks for bringing this weakness to our attention...
>> -Rick
>>
--
Knut Anders
Re: NPE from InternalTriggerExecutionContext.cleanup()
Posted by Tim Dudgeon <td...@informaticsmatters.com>.
Thanks for the response.
So its seems I'm probably right that my trigger is the ultimate cause.
Any ideas on how to work out what is failing here as the real culprit
seem to being masked.
Tim
On 29/08/2014 18:20, Rick Hillegas wrote:
> On 8/29/14 8:17 AM, Tim Dudgeon wrote:
>> Using Derby 10.10.1.1 I'm seeing strange behaviour when doing a series
>> of inserts that have triggers associated.
>> About 2000 rows get inserted fine, then it blows up completely.
>> The derby.log file contains stuff like this:
>>
>> Database Class Loader started -
>> derby.database.classpath='APP.ExtraFunctions'
>> Loaded chemaxon.misc.derby.functions.MiniregFunctions from database
>> jar "APP"."EXTRAFUNCTIONS"
>> Fri Aug 29 15:37:56 BST 2014 Thread[Default RequestProcessor,1,system]
>> (XID = 448992), (SESSIONID = 1), (DATABASE =
>> C:\Users\timbo\Documents\IJCProjects\mini-regs\Vanilla
>> Oracle/.config/derby-minireg-11-jun/db), (DRDAID = null), Cleanup
>> action starting
>> Fri Aug 29 15:37:56 BST 2014 Thread[Default RequestProcessor,1,system]
>> (XID = 448992), (SESSIONID = 1), (DATABASE = C:\Users\ ... ), (DRDAID
>> = null), Failed Statement is: INSERT INTO APP.COMPOUNDS ( ... ) VALUES
>> (?,?,?,?,?,?,?,CURRENT_TIMESTAMP,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
>> with 31 parameters begin parameter #1: BLOB:Length=1658 :end ...
>> java.lang.NullPointerException
>> at
>> org.apache.derby.impl.sql.execute.InternalTriggerExecutionContext.cleanup(Unknown
>> Source)
>> at
>> org.apache.derby.impl.sql.execute.TriggerEventActivator.cleanup(Unknown Source)
>>
>> at
>> org.apache.derby.impl.sql.execute.InsertResultSet.cleanUp(Unknown Source)
>> at
>> org.apache.derby.impl.sql.conn.GenericStatementContext.cleanupOnError(Unknown
>> Source)
>> at
>> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
>> Source)
>> at
>> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
>> Source)
>> at
>> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
>> Source)
>> at
>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
>> Source)
>> at
>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(Unknown
>> Source)
>> at
>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source)
>>
>> ...
>>
>> (somethings cut out for brevity)
>>
>>
>> The trigger involved uses a custom java function that's been added to
>> the DB, so the real problem might well be there, but the stack trace
>> doesn't give much of a pointer.
>>
>> Any suggestions for where to look?
>>
>> Tim
>>
>>
>>
> Hi Tim,
>
> This looks like a weakness in GenericStatementContext.cleanupOnError().
> The header comment for that method indicates that some more work needs
> to be done to protect the method when it trips across subsequent errors
> during statement cleanup. I have filed
> https://issues.apache.org/jira/browse/DERBY-6722 to track this defect.
>
> If I were tracking this down, I would instrument that method to make it
> print out the initial error before it calls topResultSet.cleanUp().
>
> Thanks for bringing this weakness to our attention...
> -Rick
>
Re: NPE from InternalTriggerExecutionContext.cleanup()
Posted by Rick Hillegas <ri...@oracle.com>.
On 8/29/14 8:17 AM, Tim Dudgeon wrote:
> Using Derby 10.10.1.1 I'm seeing strange behaviour when doing a series
> of inserts that have triggers associated.
> About 2000 rows get inserted fine, then it blows up completely.
> The derby.log file contains stuff like this:
>
> Database Class Loader started -
> derby.database.classpath='APP.ExtraFunctions'
> Loaded chemaxon.misc.derby.functions.MiniregFunctions from database
> jar "APP"."EXTRAFUNCTIONS"
> Fri Aug 29 15:37:56 BST 2014 Thread[Default RequestProcessor,1,system]
> (XID = 448992), (SESSIONID = 1), (DATABASE =
> C:\Users\timbo\Documents\IJCProjects\mini-regs\Vanilla
> Oracle/.config/derby-minireg-11-jun/db), (DRDAID = null), Cleanup
> action starting
> Fri Aug 29 15:37:56 BST 2014 Thread[Default RequestProcessor,1,system]
> (XID = 448992), (SESSIONID = 1), (DATABASE = C:\Users\ ... ), (DRDAID
> = null), Failed Statement is: INSERT INTO APP.COMPOUNDS ( ... ) VALUES
> (?,?,?,?,?,?,?,CURRENT_TIMESTAMP,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
> with 31 parameters begin parameter #1: BLOB:Length=1658 :end ...
> java.lang.NullPointerException
> at
> org.apache.derby.impl.sql.execute.InternalTriggerExecutionContext.cleanup(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.TriggerEventActivator.cleanup(Unknown Source)
>
> at
> org.apache.derby.impl.sql.execute.InsertResultSet.cleanUp(Unknown Source)
> at
> org.apache.derby.impl.sql.conn.GenericStatementContext.cleanupOnError(Unknown
> Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
> Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source)
>
> ...
>
> (somethings cut out for brevity)
>
>
> The trigger involved uses a custom java function that's been added to
> the DB, so the real problem might well be there, but the stack trace
> doesn't give much of a pointer.
>
> Any suggestions for where to look?
>
> Tim
>
>
>
Hi Tim,
This looks like a weakness in GenericStatementContext.cleanupOnError().
The header comment for that method indicates that some more work needs
to be done to protect the method when it trips across subsequent errors
during statement cleanup. I have filed
https://issues.apache.org/jira/browse/DERBY-6722 to track this defect.
If I were tracking this down, I would instrument that method to make it
print out the initial error before it calls topResultSet.cleanUp().
Thanks for bringing this weakness to our attention...
-Rick