[DERBY-4264] highly intermittent java.lang.ClassCastException: [[Lorg.apache.derby.iapi.store.access.Qualifier; incompatible with org.apache.derby.iapi.types.DataValueDescriptor doing simple select

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Cannot Reproduce
• Affects Version/s: 10.2.2.0
• Component/s: SQL
• Labels: derby_triage10_5_2
• Environment: Embedded Derby 10.2.2.0 - (485682); z/OS J2RE 1.5.0 IBM z/OS build pmz31dev-20081210 (SR9-0)
• Urgency: Normal
• Bug behavior facts: Seen in production
• Assignee: Katherine Marsden
• Reporter: Katherine Marsden
• Created: 09/Jun/09 16:47
• Updated: 17/Jun/13 09:19
• Resolved: 02/Nov/11 03:33

Description

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.