db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <j...@apache.org>
Subject [jira] Updated: (DERBY-3098) LOB locks are not released after free().
Date Wed, 03 Oct 2007 08:11:50 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Øystein Grøvlen updated DERBY-3098:

    Attachment: derby-3098fix.diff

The attached patch, derby-3098fix.diff, fixes the locking.  This patch
is not intended for commit since tests should be added first.

Explanation of the patch: By using READ COMMITTED instead of
REPEATABLE READ the locking will not be associated with the
transaction, but with the BaseContainerHandle. Since we use a handle
that we get from reopening the container, we get control over when the
locks are released.  The is closed when the stream is closed, or at
the end of the transaction at the latest.  (During termination of the
transaction, close will be called on all container handles).

I have also updated the comments to reflect this new implementation.
I must admit I did not quite understand the discussion in the comment
around using the isolation level of the container, but given my
proposed solution, that discussion does not relevant, and I have
deleted it from the comments.

I plan to add the following tests:

1. Check that lock on row is released at free() if isolation level of
   transaction is READ COMMITTED.
2. Check that lock on row is not released at free() if isolation level
   of transaction is REPEATABLE READ.
3. Check that lock on row is released when transaction commits.

Please, speak up, if you think more tests are necessary.

> LOB locks are not released after free().
> ----------------------------------------
>                 Key: DERBY-3098
>                 URL: https://issues.apache.org/jira/browse/DERBY-3098
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:,
>         Environment: Any
>            Reporter: Øystein Grøvlen
>            Assignee: Øystein Grøvlen
>         Attachments: derby-3098fix.diff
> When getBlob/getClob is called on the ResultSet, the current row is
> locked if the JDBC driver does not cache the entire LOB value in
> memory.  This is done to prevent the Blob/Clob object from being
> changed.  Until now, this lock has been held to the end of the
> transaction.
> JDBC4 introduced free() methods for the Blob/Clob class.  The locking
> should be changed so that the locks is releases when the Blob/Clob
> object is freed.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message