Trigger fails with ERROR XSAI2: The conglomerate (136,048) requested does not
exist possibly related to compress
----------------------------------------------------------------------------------------------------------------
Key: DERBY-5579
URL: https://issues.apache.org/jira/browse/DERBY-5579
Project: Derby
Issue Type: Bug
Environment: Derby version: 10.5.3.2 - (1073208)
ava.vendor=IBM Corporation
java.runtime.version=pwi32devifx-20110209 (SR11 FP2 +IZ94331)
java.fullversion=J2RE 1.5.0 IBM J9 2.3 Windows Server 2003 x86-32
j9vmwi3223ifx-20100511 (JIT enabled)
J9VM - 20100509_57823_lHdSMr
JIT - 20091016_1845ifx7_r8
GC - 20091026_AA
Reporter: Kathey Marsden
I do not have a lot of information on this issue but want to get it filed in
case someone sees something in the code that could cause this problem..
After the user started doing regular compress
The report was on an error:
java.sql.SQLException: The conglomerate (136048) requested does not exist.
at
org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown
Source)
at org.apache.derby.client.am.PreparedStatement.execute(Unknown Source)
at
com.ibm.team.repository.service.internal.db.jdbcwrappers.stat.PreparedStatementStatWrapper.execute(PreparedStatementStatWrapper.java:51)
ERROR XSAI2: The conglomerate (136,048) requested does not exist.
at org.apache.derby.iapi.error.StandardException.newException(Unknown
Source)
at
org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.readConglomerate(Unknown
Source)
at
org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown
Source)
at
org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown
Source)
at
org.apache.derby.impl.store.access.RAMTransaction.getDynamicCompiledConglomInfo(Unknown
Source)
at org.apache.derby.impl.sql.execute.DMLWriteResultSet.<init>(Unknown
Source)
at org.apache.derby.impl.sql.execute.DeleteResultSet.<init>(Unknown
Source)
at org.apache.derby.impl.sql.execute.DeleteResultSet.<init>(Unknown
Source)
at
org.apache.derby.impl.sql.execute.GenericResultSetFactory.getDeleteResultSet(Unknown
Source)
at
org.apache.derby.exe.acfb160050x0134xa4edxddadx000001381ca0102.fillResultSet(Unknown
Source)
at
org.apache.derby.exe.acfb160050x0134xa4edxddadx000001381ca0102.execute(Unknown
Source)
at org.apache.derby.impl.sql.GenericActivationHolder.execute(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.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.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.execute(Unknown
Source)
at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
at
org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown
Source)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown
Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
The problem statement was tracked to a trigger that had a invalid conglomerate
in its stored plan. Dropping and recreating the triggers resolved the immediate
symptoms at the user site. The root cause is thought to be related to some
sort of problem with compress that the trigger stored prepared statements did
not get invalidated.
FYI: There was a prior runtime error (not sure if it was during compress or
not). I tend to think this one may related to s JVM JIT issue.
java.sql.SQLException: The heap container with container id Container(-1,
1320304910265) is closed.
I don't have a stack trace for that one, but wonder if compress fails, is it
possible that the compression could take place but we don't invalidate the
statements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
