[
https://issues.apache.org/jira/browse/DERBY-5752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-5752:
--------------------------------------
Attachment: d5752-1a.diff
The attached patch, d5752-1a.diff, changes LOBStreamControl's constructor so
that it doesn't materialize LOBs larger than 32 KB in memory. It also adds a
test case to BlobMemTest, which fails with an OOME without the fix.
All the regression tests ran cleanly. However, I noticed that BlobClob4BlobTest
took significantly longer with the patch. Specifically, the time it took to run
test case testPositionAgressive() in an encrypted database increased from 20
seconds to more than 4 minutes. I look into it and try to find out why this
particular test case gets so much slower.
> 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.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Fix For: 10.9.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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
