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] Commented: (DERBY-3354) Select from large lob table with embedded gives OutOfMemoryError
Date Tue, 29 Jan 2008 14:54:34 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563539#action_12563539
] 

Knut Anders Hatlen commented on DERBY-3354:
-------------------------------------------

> I believe this is because EmbedConnection.addLobMapping is called for every lob creation
but is never cleared until commit or rollback, even if the lob is freed.

I believe your analysis is correct. free() should remove the mapping. Unfortunately, the lob
doesn't know about its locator value, but it seems like your about to change that by adding
a getLocator() method in DERBY-3243.

On DERBY-3243 I wrote:
> Another thing I came to think about: Would it be better to remove addLOBMapping() from
the constructors in EmbedBlob/EmbedClob and instead call it lazily from getLocator()? (...)
Then we'd also remove the overhead of maintaining the lob mapping in embedded mode.

I think that change would fix the OOME (on embedded, but we'd probably still see it in a client/server
environment).

Now, it seems like DERBY-2787 added the call to addLOBMapping() intentionally to ensure that
free() was called on commit/rollback and temporary files would be deleted. Moving addLOBMapping()
out of the constructors would probably reintroduce the problem with temporary files not being
deleted. However, the lobs only create temporary files when they are modified and the new
size of the lob is greater than the buffer in LOBStreamControl, so it shouldn't be necessary
to have commit/rollback call free() on all lobs to delete the temporary files. It would probably
be enough if each lob added itself to a list in the connection each time a temporary file
was created in LOBStreamControl.init(). (addLOBMapping() is probably OK, but it feels a bit
strange to piggyback on a locator mechanism to do this cleanup when we don't actually care
about the locators.)

> Select from large lob table with embedded gives OutOfMemoryError
> ----------------------------------------------------------------
>
>                 Key: DERBY-3354
>                 URL: https://issues.apache.org/jira/browse/DERBY-3354
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>            Reporter: Kathey Marsden
>         Attachments: LocLeak.java
>
>
> Retrieving from a large table with lobs gives an OutOfMemoryException, even if free()
is explictly called on the lob.   I believe this is because EmbedConnection.addLobMapping
is called for every lob creation but is never cleared until commit or rollback, even if the
lob is freed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message