Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <29950384.1203082333113.JavaMail.jira@brutus>
Date: Fri, 15 Feb 2008 05:32:13 -0800 (PST)
From: =?utf-8?Q?=C3=98ystein_Gr=C3=B8vlen_=28JIRA=29?= <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-3354) Select from large lob table with
 embedded gives OutOfMemoryError
In-Reply-To: <20467307.1201549894825.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-3354?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1256=
9268#action_12569268 ]=20

=C3=98ystein Gr=C3=B8vlen commented on DERBY-3354:
----------------------------------------

Kathey, I agreed that more needs to be done for a final patch.  I just put =
together a patch with the core fix to make it possible to try out the fix.

To your issues:
1) Creating a finally block in EmbedBlob seems like a good idea.  I also ag=
ree that we can remove similar code from the stored procedures.

2) I will think about solution for jdk15. The problem introduced by 10.3 is=
 that the lob mapping keeps Blob/Clob objects alive that earlier would be g=
c'ed when it was no longer referred by the user.  I guess another level of =
indirection would make it possible to use finalizers to clean up, but I am =
not sure that is a good idea.
A work-around is to not create Blob objects in the first place, but use Res=
ultSet#getBytes etc instead.  So the problem is limited to the case where a=
 Blob object need to be accessible after a call to ResultSet#next, but not =
until commit.

3) Seems like there is come concurrent access to the HashMap.  I would gues=
s that this is because the iterator created by rollback, detects that the u=
nderlying collection has been changed.  Probably through the calls to free =
in the loop using the iterator.  I think this show that something needs to =
be reorganized a bit here.


> 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
>    Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
>            Reporter: Kathey Marsden
>         Attachments: derby-3354.diff, LocLeak.java
>
>
> Retrieving from a large table with lobs gives an OutOfMemoryException, ev=
en if free() is explictly called on the lob.   I believe this is because Em=
bedConnection.addLobMapping is called for every lob creation but is never c=
leared until commit or rollback, even if the lob is freed.

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