db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3571) LOB locators are not released if the LOB columns are not accessed by the client
Date Wed, 26 Mar 2008 16:27:24 GMT

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


Mime
View raw message