[
https://issues.apache.org/jira/browse/DERBY-5752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen resolved DERBY-5752.
---------------------------------------
Resolution: Fixed
Fix Version/s: 10.10.0.0
Issue & fix info: (was: Patch Available)
Committed revision 1447722.
> LOBStreamControl should materialize less aggressively
> -----------------------------------------------------
>
> Key: DERBY-5752
> URL: https://issues.apache.org/jira/browse/DERBY-5752
> Project: Derby
> Issue Type: Improvement
> Components: JDBC
> Affects Versions: 10.9.1.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Fix For: 10.10.0.0
>
> Attachments: buffsize.diff, d5752-1a.diff
>
>
> The constructor LOBStreamControl(EmbedConnection, byte[]) always makes the
> buffer size equal to the LOB size, effectively creating an extra, fully
> materialized copy of the LOB in memory.
> I think the assumption here is that a LOB that's already materialized is a
> small one. That is, LOBs that are smaller than 32 KB and fit in a single page
> are typically materialized when read from store. However, we sometimes
> materialize LOBs that are a lot bigger than 32 KB. For example, triggers that
> access LOBs may materialize them regardless of size (see comment in
> DMLWriteResultSet's constructor for details). For these large LOBs, it sounds
> unreasonable to allocate a buffer of the same size as the LOB itself.
> I'd suggest that we change the constructor so that it never allocates a
> buffer larger than 32KB. That would mean that the behaviour is preserved for
> all LOBs fetched directly from store (only LOBs that don't fit in a single
> page will cause temporary files to be created), whereas we'll prevent large
> LOBs accessed by triggers from being duplicated in memory by overflowing to
> temporary files.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
