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 Wed, 29 Oct 2008 13:11: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-1b-cacheCharLength.diff

Thanks for looking at the patch Knut Anders.

To confirm your observations, the StoreStreamClob is indeed a read-only representation of
a Clob. This is a requirement for the patch.
I removed some invalid comments from the patch and uploaded a new version (1b). When my test
runs are done, I will commit it.

In the "near future" (TM) I hope the length information will be stored in the stream for all
Clobs. This will require changes in the same area of the code.
Even if this patch helps performance for subsequent length calls, we still have to decode
the data once to get the length.

> 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: 10.3.1.4
>            Reporter: Kristian Waagan
>         Attachments: derby-2822-1a-cacheCharLength.diff, derby-2822-1b-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
operations.
> 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
length?

-- 
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