db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5752) LOBStreamControl should materialize less aggressively
Date Fri, 11 May 2012 11:09:50 GMT

     [ 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

        

Mime
View raw message