[
https://issues.apache.org/jira/browse/DERBY-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724903#action_12724903
]
Knut Anders Hatlen commented on DERBY-4264:
-------------------------------------------
You're right, the back-pointers don't make much sense for DirectCall. We'll
know which of the e* methods is being called, and also which
Activation/GeneratedByteCode it was called on, so it should be easy to see if
the method actually did return a Qualifier[][]. I don't see any more useful
information that's easily available at this point. It's probably better to wait
for the diagnostics from this patch before adding more instrumentation, as
you'll probably know more about what to look for then.
> highly intermittent java.lang.ClassCastException:
> [[Lorg.apache.derby.iapi.store.access.Qualifier; incompatible with
> org.apache.derby.iapi.types.DataValueDescriptor doing simple select
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4264
> URL: https://issues.apache.org/jira/browse/DERBY-4264
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.2.2.0
> Environment: Embedded Derby 10.2.2.0 - (485682)
> z/OS J2RE 1.5.0 IBM z/OS build pmz31dev-20081210 (SR9-0)
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Attachments: acf81e0010x0121xcb69x9b94x0000000eb0100.java,
> derby-4264_10.2_diag_diff.txt, derby-4264_10.2_diag_diff.txt
>
>
> I got a report from a user for a highly intermittent ClassCastException doing
> a select. Below is the stack trace:
> java.lang.ClassCastException:
> [[Lorg.apache.derby.iapi.store.access.Qualifier; incompatible
> with org.apache.derby.iapi.types.DataValueDescriptor
> at
> org.apache.derby.impl.sql.execute.GenericQualifier.getOrderable(
> Unknown Source)
> at
> org.apache.derby.impl.sql.execute.NoPutResultSetImpl.clearOrdera
> bleCache(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openSca
> nController(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Un
> known Source)
> at
> org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openCor
> e(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(U
> nknown Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unkno
> wn Source)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unkno
> wn Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(Unknown
> Source)
> I don't have a reproduction yet but have some information on the schema and
> query that occasionally fails: The data here is contrived, I don't know the
> actual data in the table at the time of the failure. The column names have
> changed, but represent the same types.
> CREATE TABLE "APP"."RESOURCE"
> (
> "AUUID" CHAR(36) NOT NULL,
> "BUUID" CHAR(36) NOT NULL,
> "CUUID" CHAR(36) NOT NULL,
> "DUUID" CHAR(36) NOT NULL,
> "SECTION" CHAR(6) NOT NULL,
> "TYPE" CHAR(48) NOT NULL,
> "LASTUPDATE" TIMESTAMP NOT NULL
> );
> ALTER TABLE "APP"."RESOURCE" ADD CONSTRAINT "SQL060817095529130" PRIMARY KEY
> ("AUUID", "BUUID", "SECTION");
> -- Not sure of the actual data. This data was made up so the query would get
> a match.
> INSERT INTO RESOURCE VALUES ('3b2c2edc-1401-0000-0080-c38634aef3ba',
> '3b2c2edc-1401-0000-0080-c38634aef3bb',
> '2be1347d-2001-0000-0080-8cd524f0d034',
> '2be1347d-2001-0000-0080-8cd524f0d033', 'GENRAL', 'NodeType',
> CURRENT_TIMESTAMP);
> SELECT * FROM RESOURCE WHERE
> SECTION='GENRAL' AND
> TYPE='NodeType' AND
> DUUID='2be1347d-2001-0000-0080-8cd524f0d033' AND
> BUUID='3b2c2edc-1401-0000-0080-c38634aef3bb';
> This has happened to just one user on z/OS with J2RE 1.5.0 IBM z/OS build
> pmz31dev-20081210 (SR9-0). Other users running the same application on the
> same versions have not seen this issue. This particular user has disabled
> the functionality causing the problem for now, so I am hoping we can glean
> some information from code inspection and debugging this sample query to see
> where the cast might go wrong.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
