[
https://issues.apache.org/jira/browse/DERBY-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639064#action_12639064
]
Knut Anders Hatlen commented on DERBY-3825:
-------------------------------------------
I read through the patch, and it looks correct to me. The repositioning logic
was rather complex, mainly because of the buffering and the mix of 1-based
indexes on the JDBC level and 0-based indexes on the buffer level, but it looks
to me as if all cases are handled correctly.
I have also tested the patch by fetching a 32 MB CLOB with getSubString().
Without the patch, it took so long time that I hit Ctrl-C in the end (waited
for minutes). With the patch, it took 3-4 seconds to fetch the CLOB. So the
patch seems to work very well! This was with a CLOB stored in a table. When I
tested the same with a CLOB created by Connection.createClob(), I still
observed that getSubString() took a very long time. I suppose this is what's
meant by the TODO comment in TemporaryClob?
I noticed a TODO that suggested that localization was going to be added in
UTF8Reader.skipPersistent(). Is this planned in a follow-up patch? Other places
in the code, we just throw an EOFException with no message in similar
situations. Perhaps the detailed error message could be put in a THROWASSERT()
so that it is only used in debug builds?
The class javadoc for UTF8ReaderTest says that it tests "package-private
methods in [EMAIL PROTECTED] UTF8Reader}." As far as I can see, it only tests
the public methods of UTF8Reader.
> StoreStreamClob.getReader(charPos) performs poorly
> --------------------------------------------------
>
> Key: DERBY-3825
> URL: https://issues.apache.org/jira/browse/DERBY-3825
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Store
> Affects Versions: 10.5.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: derby-3825-0a-preview.diff,
> derby-3825-1a-reset_readpositioninbuffer.diff,
> derby-3825-2a-internalReader_repositioning.diff,
> derby-3825-2a-internalReader_repositioning.stat
>
>
> StoreStreamClob.getReader(charPos) performs poorly because it resets the
> underlying stream and skips data until it reached the requested character
> position. Not only does the data has to be skipped, it also has to be decoded
> (UTF-8).
> The problem is exposed through EmbedClob.getSubString, which causes extremely
> bad performance for the client driver because the locator based Clob
> implementation uses this method.
> For the record, there is another read buffer size issue that exaggerates the
> problem (it will probably be handled under DERBY-3769, and also DERBY-3818).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
