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-3571) LOB locators are not released if the LOB columns are not accessed by the client
Date Tue, 01 Apr 2008 09:48:27 GMT

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

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

b) You're of course right, I had missed that. No need to set it to true, except perhaps for
readability. The rename sounds like a good idea.

c) It's probably not necessary to throw the assert or an exception, since Arrays.binarySearch()
returns a negative value if it cannot be found, and then we'll get an ArrayIndexOutOfBoundsException
immediately when we update the array, so the error won't go unnoticed. By the way, is markAccessed
a better name than noRelease for this method?

e) Such an optimization could wait if it is too much work. Seems like the easiest way to get
this information is to factor out some of the logic from Statement.resultSetCommitting().

Using a single shared tracker implementation sounds good. My concern is that we add the BatchReleaseLOBTracker
only for the 10.4 release, and get some code that we need to maintain forever for backward
compatibility (like the stored procedure to release a range of LOBs) although it's only needed
for a single minor release. Perhaps, if the plan is to implement the piggybacking for 10.5,
it would be a better long-term solution to skip the BatchReleaseLOBTracker and let 10.4 use
the less efficient SingleReleaseLOBTracker?

> LOB locators are not released if the LOB columns are not accessed by the client
> -------------------------------------------------------------------------------
>
>                 Key: DERBY-3571
>                 URL: https://issues.apache.org/jira/browse/DERBY-3571
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Network Client
>    Affects Versions: 10.3.2.1, 10.4.0.0, 10.5.0.0
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>         Attachments: derby-3571-1a-client_track_lob_fix.diff, derby-3571-1a-client_track_lob_fix.stat,
derby-3571-1b-client_track_lob_fix.diff, derby-3571-1c-client_track_lob_fix.diff, derby-3571-1d-client_track_lob_fix.diff,
derby-3571-1e-client_track_lob_fix.diff
>
>
> If the client creates a result set containing LOB locator columns and iterates through
it without actually accessing the LOB columns, the locators are not released.
> The amount of locators and their associated LOB objects causes the server to consume
large amounts of memory and it eventually gets an OOME.
> There are a few workarounds for this bug:
>  a) Access and/or properly close the LOBs (i.e. Blob.free).
>     This is partly dependent on DERBY-2892.
>  b) Invoke Connection.commit (or rollback) periodically, which causes all locators on
the connection to be released.

-- 
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