db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2822) Add caching of store stream length in StoreStreamClob, if appropriate
Date Tue, 05 Aug 2008 13:54:44 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Kristian Waagan updated DERBY-2822:

    Attachment: derby-2822-1a-cacheCharLength.diff

'derby-2822-1a-cacheCharLength.diff' is a suggestion on how to add caching of the char length
for store stream Clobs.

Unfortunately we won't be able to reach the optimal performance on getting the length of a
Clob, because we don't store the required information. There are two issues:
 a) The number of bytes set aside for storing length information is insufficient (2 bytes).
    This means longer Clobs won't have the byte length stored at the head of the stream.
 b) We store only the number of bytes, not the number of characters.
    Since we are using the UTF-8 format, knowing the byte length doesn't give us the character

As a first step we should add caching of the length.
On a longer term we should implement a reasonable scheme for storing length information. There
are several issues to consider, so we need a discussion on this.

suites.All ran without failures with patch 1a.
Patch ready for review/comments.

> Add caching of store stream length in StoreStreamClob, if appropriate
> ---------------------------------------------------------------------
>                 Key: DERBY-2822
>                 URL: https://issues.apache.org/jira/browse/DERBY-2822
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC
>    Affects Versions:
>            Reporter: Kristian Waagan
>            Priority: Minor
>         Attachments: derby-2822-1a-cacheCharLength.diff
> Currently StoreStreamClob reads the whole Clob stream, including decoding it, to find
the length of it. It also does this the second time the length is asked for.
> StoreStreamClob is the internal Clob representation for Clobs that are read-only. As
soon as the user updates the Clob, it is transferred to a modifiable Clob representation.
> It should be determined if it is safe to cache the length (both in bytes and in characters)
of the store stream to improve the performance and reduce the load on Derby for certain Clob
> To do this, the locking mechanism used for Clobs must be analyzed.
> If you have obtained a Clob object, is there a lock in place that stops others from changing
the content?
> For all isolation levels?
> What about scrollable result sets?
> Can the streamed content from store be changed under us, and thus invalidate a cached

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

View raw message