[
https://issues.apache.org/jira/browse/DERBY-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637907#action_12637907
]
Kristian Waagan commented on DERBY-2822:
----------------------------------------
It should be noted that the client driver already caches the LOB lengths (for
both Clobs and Blobs).
I planning to go ahead with the patch for StoreStreamClob in the embedded
driver.
> 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
>
>
> 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.
