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 Tue, 01 Apr 2008 20:22: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-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.


Mime
View raw message