Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger

• Key: DERBY-1435
• Type: Bug
• Status: Closed
• Resolution: Duplicate
• Priority: Major
• Assignee: Yip Ng
• Reporter: Deepa Remesh
• Component/s: SQL
• Affects Version/s: 10.2.1.6
• Fix Version/s: 10.2.1.6

Description

This exception occurs in the following case:

1. Create tables t1 and t2. Create a trigger on t2 whose triggering action is to insert a row into t1
2. Insert a value v1 into t2. Verify the trigger was fired by looking at contents of t1.
3. Drop table t1.
4. Insert a value v2 into t2. This will give an exception to indicate that table t1 does not exist.
5. Insert the same value v1 into t2. Instead of the exception in Step 4, this gives "ERROR XSAI2: The conglomerate (896) requested does not exist."
6. Re-create table t1.
7. Insert v2 into t2. This succeeds.
8. Try to insert the problem value v1 into t2. This still gives "ERROR XSAI2: The conglomerate (896) requested does not exist."
9. Shutdown and reconnect to the database. Try to insert the problem value v1 into t2. Now this succeeds.

So the exception occurs only in the specific case where we try to insert the same value that we had inserted before dropping the table referenced by the trigger. I'll attach a sql script to repro this.

Comments

[Deepa Remesh]

Attaching a sql script 'repro1435.sql' to repro this issue

[Suresh Thalamati]

Good catch deepa. My guess is the plans in the statement cache are not getting invalidated corretcly when table t1 is dropped. I tried the repro by setting the statement cache value to zero ( derby.language.statementCacheSize=0), when I do that I did not get any "The conglomerate (896) requested does not exist" errors. I think the problem may not be in the store layer.
 
Thanks
-suresht

[Øystein Grøvlen]

I have sometimes seen the same error message in another context. See DERBY-637. No triggers involved in my case and not easily reproduced (but I have seen it several times). I had to shutdown and restart the database to make the error disappers.

[Deepa Remesh]

Thanks for looking into this Suresh. Now, I can see this from the traces too. We are re-using the prepared statement after table t1 is dropped. Here are the stack traces from ij for execution of a new statement (insert into t2 values(2)) and a previously executed statement (insert into t2 values(1)) after table t1 is dropped:

ij> --- these inserts should not work, but the second insert gives XSAI2
insert into t2 values(2);
ERROR 42X05: Table/View 'T1' does not exist.
ERROR 42X05: Table/View 'T1' does not exist.
        at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:304)
        at org.apache.derby.impl.sql.compile.DMLModStatementNode.verifyTargetTable(DMLModStatementNo
de.java:230)
        at org.apache.derby.impl.sql.compile.InsertNode.bind(InsertNode.java:248)
        at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:344)
        at org.apache.derby.impl.sql.GenericStatement.prepareStorable(GenericStatement.java:591)
        at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.compileStatement(SPSDescriptor.java:35
3)
        at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(SPSDescriptor.java:2
83)
        at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(SPSDescriptor.java:3
03)
        at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(SPSDescriptor.jav
a:690)
        at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(SPSDescriptor.jav
a:651)
        at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecuto
r.java:138)
        at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(RowTriggerExecutor.java:
110)
        at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator
.java:277)
        at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1
134)
        at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:522)
        at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:
361)
        at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1181)
        at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584)
        at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516)
        at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:313)
        at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433)
        at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310)
        at org.apache.derby.impl.tools.ij.Main.go(Main.java:207)
        at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:173)
        at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
        at org.apache.derby.tools.ij.main(ij.java:60)
ij> insert into t2 values(1);
ERROR XSAI2: The conglomerate (896) requested does not exist.
ERROR XSAI2: The conglomerate (896) requested does not exist.
        at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:304)
        at org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.readConglomerate(HeapCong
lomerateFactory.java:224)
        at org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(RAMAccessManager.jav
a:484)
        at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(RAMTransaction
.java:389)
        at org.apache.derby.impl.store.access.RAMTransaction.getDynamicCompiledConglomInfo(RAMTransa
ction.java:701)
        at org.apache.derby.impl.sql.execute.DMLWriteResultSet.<init>(DMLWriteResultSet.java:82)
        at org.apache.derby.impl.sql.execute.DMLWriteResultSet.<init>(DMLWriteResultSet.java:66)
        at org.apache.derby.impl.sql.execute.InsertResultSet.<init>(InsertResultSet.java:343)
        at org.apache.derby.impl.sql.execute.GenericResultSetFactory.getInsertResultSet(GenericResul
tSetFactory.java:95)
        at org.apache.derby.exe.ac46a08075x010bxfc52x1188x0000001171d80.fillResultSet(Unknown Source
)
        at org.apache.derby.exe.ac46a08075x010bxfc52x1188x0000001171d80.execute(Unknown Source)
        at org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:32
6)
        at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:
359)
        at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecuto
r.java:169)
        at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(RowTriggerExecutor.java:
110)
        at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator
.java:277)
        at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1
134)
        at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:522)
        at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:
361)
        at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1181)
        at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584)
        at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516)
        at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:313)
        at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433)
        at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310)
        at org.apache.derby.impl.tools.ij.Main.go(Main.java:207)
        at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:173)
        at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
        at org.apache.derby.tools.ij.main(ij.java:60)

[Deepa Remesh]

A similar case occurs when function/procedure referenced in triggered SQL statement is dropped and a previously executed statement is re-executed to fire the trigger. In this case, no exception is thrown; the trigger firing is successful (executes the function/procedure as if it had not been dropped).

The new repro 'repro1435_for_functions.sql' shows this. Also, I see a different behaviour in the execution of a statement when it is preceded with a comment. This is also included in the repro. I am adding this to the same issue as the problems look similar.

[Kathey Marsden]

This is definitely a Normal+, not a regression, but ugly. It should be at least documented in the release notes.

[Daniel John Debrunner]

I assume in the original description inserting the same value really means using the same SQL statement, ie. inserting different values using the same statement with parameter markers would cause the conglomerate not found exception.

[Deepa Remesh]

Yes. This issue occurs when using the same statement (that was used before dropping the database object referenced in the trigger's action statement).

[Yip Ng]

This is a duplicate to DERBY-1621.

[Yip Ng]

This issue is resolved by DERBY-1621. Please refer to the release note on that issue.

[Andrew McIntyre]

This issue has been resolved for over a year with no further movement. Closing.