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