You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <ji...@apache.org> on 2008/04/01 22:22:24 UTC

[jira] Updated: (DERBY-3571) LOB locators are not released if the LOB columns are not accessed by the client

     [ 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-2a-simple_release.stat
                derby-3571-2a-simple_release.diff

'derby-3571-2a-simple_release.diff' deprecates patch revision 1.

The patch implements only the simple release mechanism (one locator at a time). Thanks to Knut Anders for commenting on the compatibility issues.
I have addressed comment (c), but chose to skip/postpone item (e), and added some simple tests. The tests are mainly for checking that the code works to some degree, it doesn't check that the code works optimally or entirely correct.

I have also added a workaround in checkCurrentRow for something that is really a problem in ResultSet.
I am not easily able to determine if the current row has changed on all the navigational methods, and checkCurrentRow will fail if called twice on the same row (the locators are already released). I added lastSeenLocator, and upon release time the current locator is checked with the last one seen for the column. If they are equal, checkCurrentRow returns immediately.

I looked at using information in ResultSet to avoid calling the method multiple times on the same row, but couldn't find a solution quickly. If you know about one, let me know :)
As an example of how to provoke the problem, consider calling rs.absolute(X) twice or rs.moveToCurrentRow() twice.

I have run derbynet, jdbc4 and jdbcapi without errors. I'm currently running suites.All and derbyall.

It is my opinion that this patch may change the premises for DERBY-2892 and possibly DERBY-3583. It would therefore be nice if we could get this patch in as soon as possible.

Please review.


> 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, derby-3571-2a-simple_release.diff, derby-3571-2a-simple_release.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.