db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3219) Group by query with many aggregate columns and case statements fails with: ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was originally stored
Date Tue, 13 May 2008 03:06:55 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596257#action_12596257
] 

Bryan Pendleton commented on DERBY-3219:
----------------------------------------

I'm increasingly convinced that the problem lies in SQLChar.readExternal,
due to the fact that it can't tell the difference between a true string-of-length-0,
and a string which is longer than 65536 bytes in length, and therefore is
being "streamed" with a 0 length.

That is, for a string with a length < 65536, SQLChar.readExternal expects:
 - 2 byte actual length of the string
 - the string's bytes
While for a string with a length >= 65536, SQLChar.readExternal expects:
 - 2 byte length code with a value of 0
 - the string's bytes
 - a special 3-byte marker sequence that indicates that the string is complete

The problem is that with a string-of-length-0, SQLChar.readExternal can't
tell the difference. It sees the length of 0, and doesn't know whether it
will be followed by 0 bytes of actual data, or by at least 65536 bytes of
actual data.

I've had two ideas:

1) If we are allowed to change the data format used by readExternal/writeExternal,
we could change the externalized representaiton of the string-of-length-0
so that it was:
 - two byte length code (0)
 - 0 bytes of actual string data
 - 3 byte EOF marker sequence
This way, if we ever saw the initial length code set to 0, we'd know that
we'd *always* read until we saw the 3-byte EOF marker sequence, and
it would *never* be acceptable to read until EOF

2) If we are not allowed to change the SQL char external data format, then
perhaps we could tell the difference after the fact by realizing that we hit an
EOF exception after a non-zero number of bytes were read, but before 65536+
bytes were read, and therefore we accidentally processed a string-of-length-0
in such a way as to "gobble" data that wasn't ours, and perhaps we could
then use an algorithm which would "mark" the input stream and be able
to push back the data we weren't supposed to have read, by restoring back
to the mark.

Anybody know if we're allowed to change the format used by SQLChar.read/writeExternal?


> Group by query with many aggregate columns and case statements fails with: ERROR XSDA7:
Restore of a serializable or SQLData object of class , attempted to read more data than was
originally stored
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3219
>                 URL: https://issues.apache.org/jira/browse/DERBY-3219
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.3.1.4
>            Reporter: Stan Bradbury
>         Attachments: pivotView.zip
>
>
> using the attached database (v10.3) - " select * from pivotview " fails with the stack
trace below.  A view (pivotview_ok) created on a subset of the columns in pivotview executes
fine.  Adding one column back into pivotview_ok causes failures most of the time.  See attached
for view definitions.
> 2007-11-21 00:58:49.421 GMT Thread[main,5,main] (XID = 2734422), (SESSIONID = 0), (DATABASE
= pivotview), (DRDAID = null), Failed Statement is: select * from pivotview
> ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read
more data than was originally stored
> 	at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.StreamFileContainer.fetchNext(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.StreamFileContainerHandle.fetchNext(Unknown
Source)
> 	at org.apache.derby.impl.store.access.sort.MergeScan.mergeARow(Unknown Source)
> 	at org.apache.derby.impl.store.access.sort.MergeScan.init(Unknown Source)
> 	at org.apache.derby.impl.store.access.sort.MergeSort.openSortScan(Unknown Source)
> 	at org.apache.derby.impl.store.access.RAMTransaction.openSortScan(Unknown Source)
> 	at org.apache.derby.impl.sql.execute.GroupedAggregateResultSet.loadSorter(Unknown Source)
> 	at org.apache.derby.impl.sql.execute.GroupedAggregateResultSet.openCore(Unknown Source)
> 	at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source)
> 	at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.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.EmbedStatement.execute(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source)
> 	at org.apache.derby.tools.ij.main(Unknown Source)
> Caused by: java.io.EOFException
> 	at java.io.DataInputStream.readBoolean(DataInputStream.java:248)
> 	at org.apache.derby.impl.sql.execute.MaxMinAggregator.readExternal(Unknown Source)
> 	at org.apache.derby.iapi.services.io.FormatIdInputStream.readObject(Unknown Source)
> 	at org.apache.derby.iapi.types.UserType.readExternal(Unknown Source)
> 	... 22 more
> ============= begin nested exception, level (1) ===========
> java.io.EOFException
> 	at java.io.DataInputStream.readBoolean(DataInputStream.java:248)
> 	at org.apache.derby.impl.sql.execute.MaxMinAggregator.readExternal(Unknown Source)
> 	at org.apache.derby.iapi.services.io.FormatIdInputStream.readObject(Unknown Source)
> 	at org.apache.derby.iapi.types.UserType.readExternal(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.StreamFileContainer.fetchNext(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.StreamFileContainerHandle.fetchNext(Unknown
Source)
> 	at org.apache.derby.impl.store.access.sort.MergeScan.mergeARow(Unknown Source)
> 	at org.apache.derby.impl.store.access.sort.MergeScan.init(Unknown Source)
> 	at org.apache.derby.impl.store.access.sort.MergeSort.openSortScan(Unknown Source)
> 	at org.apache.derby.impl.store.access.RAMTransaction.openSortScan(Unknown Source)
> 	at org.apache.derby.impl.sql.execute.GroupedAggregateResultSet.loadSorter(Unknown Source)
> 	at org.apache.derby.impl.sql.execute.GroupedAggregateResultSet.openCore(Unknown Source)
> 	at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source)
> 	at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.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.EmbedStatement.execute(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
> 	at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source)
> 	at org.apache.derby.tools.ij.main(Unknown Source)
> ============= end nested exception, level (1) ===========
> Cleanup action completed

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message