[
https://issues.apache.org/jira/browse/DERBY-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-2584:
--------------------------------------
Attachment: initiallyCompilable.diff
I don't know exactly what's happening, but it seems like an attempt to store
the SPS for getIndexInfo() in a nested transaction fails because the parent
transaction holds a shared lock on SYSSTATEMENTS. Therefore, an attempt is made
to store the SPS in the parent transaction, and that succeeds. However, the SPS
that is stored is not complete, so the next call to getIndexInfo() fails.
SPSDescriptor.updateSYSSTATEMENTS() and DataDictionaryImpl.updateSPS() have
some logic to ensure that parts of the stored statement are only updated the
first time the statement is prepared. But since the first failed attempt in the
nested transaction is counted as the first compile, the update in the main
transaction does not update everything correctly.
The attached patch restores some of the state (one boolean
field--initiallyCompilable) when the first update times out, so that the update
in the main transaction is regarded as the first compilation. This makes the
repro run without errors. Does this sound like a reasonable approach? I have
not run any tests yet.
> Creating a database with JPOX SchemaTool sometimes gives
> ArrayIndexOutOfBoundsException when getIndexInfo() is called
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2584
> URL: https://issues.apache.org/jira/browse/DERBY-2584
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.2.2.0
> Reporter: Bernt M. Johnsen
> Attachments: d2584.java, initiallyCompilable.diff
>
>
> It has been reported (e.g. here:
> http://www.jpox.org/servlet/forum/viewthread?thread=4034 ) that the database
> sometimes get corrupt when the db is created with JPOX SchemaTool. This leads
> to java.lang.ArrayIndexOutOfBoundsException for some (at least one:
> getIndexInfo) metadata calls. When this happens, the types array
> GenericParameterValueSet.initialize has length 0.
> I have not yet managed to reproduce the bug in a small repro. A workaround
> exists though: Create the database before you run the JPOX SchemaTool.
> The stack trace you get when getIndexInfo is called is
> 2007-04-17 16:20:20.191 GMT Thread[DRDAConnThread_5,5,main] (XID = 1554),
> (SESSIONID = 10), (DATABASE = communitymc_portal1), (DRDAID =
> C0124DC3.H92B-954198994222304164{11}), Failed Statement is: CALL
> SYSIBM.SQLSTATISTICS(?,?,?,?,?,?) with 6 parameters begin parameter #1: null
> :end parameter begin parameter #2: PORTAL :end parameter begin parameter #3:
> COMMUNITY :end parameter begin parameter #4: 1 :end parameter begin parameter
> #5: 1 :end parameter begin parameter #6:
> DATATYPE='JDBC';DYNAMIC=0;REPORTPUBLICPRIVILEGES=1;CURSORHOLD=1 :end parameter
> java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.derby.impl.sql.GenericParameterValueSet.initialize(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.BaseActivation.setupActivation(Unknown
> Source)
> at org.apache.derby.impl.sql.GenericActivationHolder.<init>(Unknown
> Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown
> Source)
> at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.prepareMetaDataStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.prepareSPS(Unknown Source)
> at
> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQueryUsingSystemTables(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQuery(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQuery(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.doGetIndexInfo(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getIndexInfo(Unknown Source)
> at org.apache.derby.catalog.SystemProcedures.SQLSTATISTICS(Unknown
> Source)
> at
> org.apache.derby.exe.ac72e9c096x0112x0056x2b09xffffcd3424e39.g0(Unknown
> Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.CallStatementResultSet.open(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.EmbedCallableStatement.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)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
