[
https://issues.apache.org/jira/browse/DERBY-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-3571:
-----------------------------------
Attachment: derby-3571-1a-client_track_lob_fix.stat
derby-3571-1a-client_track_lob_fix.diff
'derby-3571-1a-client_track_lob_fix.diff' is the first attempt at a fix where
the client keeps track of LOBs and closes them as appropriate.
The basic approach is:
a) When the result set position is changed, check the current row (if any)
for LOB columns with open locators.
b) When the result set is closed, check the current row (if any).
c) If a Blob or Clob object is created, inform the state tracker that its
locator shall not be released.
d) On connection commit/rollback, discard all client side LOB state as all
locators are released by the server.
Currently there will be a callable procedure invocation (and thus a round trip)
for each LOB column each time the result set position changes (i.e. rs.next or
rs.relative). This is very ineffective, and for the current solution there are
two optimizations that can be made:
1) Implement a new stored procedure that takes a list of locators. All
locators are freed in one round trip. The complication is to decide when the
procedure should be invoked, i.e. there must typically be some kind of
threshold (number of locators).
2) Piggy-back locators on other requests to the server. Frees resources
optimally at almost no extra cost. There are several variations, for instance
doing it on the connection level or only on the resultset/cursor level (CNTQRY).
Since we don't do prefetching of result set data containing LOBs, the
difference between the optimizations is less pronounced, but (1) will most
likely leave resources open for a longer period of time on the server.
Another thing to consider is how important it is that this feature is very
effective. Why query the database for data you don't need?
Please review and comment.
I'm running tests, and I have run the repro mentioned in DERBY-2892 without
failure.
> 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.1.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
>
>
> 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.
