[
https://issues.apache.org/jira/browse/DERBY-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650544#action_12650544
]
Kristian Waagan commented on DERBY-2822:
----------------------------------------
Backported patch 1b to the 10.4 branch with revision 720472.
I will close this issue when the nightly/tinderbox tests have been run.
> 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
> Assignee: Kristian Waagan
> Fix For: 10.4.2.1, 10.5.0.0
>
> 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.
