db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-255) Closing a resultset after retrieving a large > 32K value with Network Server does not release locks
Date Fri, 03 Jun 2005 04:33:52 GMT
     [ http://issues.apache.org/jira/browse/DERBY-255?page=all ]

Kathey Marsden updated DERBY-255:

    Attachment: DERBY-255_irc_6_2_2005

Sunitha and I chatted on IRC about DERBY-255. First transcript was lost but recapped in the

* Since we cannot traverse the stream twice to get length and then data Network Server currently
does getBytes for Blob calls and needs sufficient JVM memory allocated.
* Real solution is 
   1) DERBY-326 to enable streaming without the length.
   2) DERBY-327 to use lob locators for performance and differentiation of client calls
      to getBlob vs getBinaryStream for locking.
* As an aside noted that the embedded  Blob.length() call could probably use available(),
skip() to improve performance instead of reading the data.

> Closing a resultset after retrieving a large > 32K value with Network Server does
not release locks
> ---------------------------------------------------------------------------------------------------
>          Key: DERBY-255
>          URL: http://issues.apache.org/jira/browse/DERBY-255
>      Project: Derby
>         Type: Bug
>     Versions:,,,
>     Reporter: Kathey Marsden
>     Assignee: Kathey Marsden
>      Fix For:
>  Attachments: DERBY-255_irc_6_2_2005, LargeDataLocks.java, derby255.diff
> Closing a resultset after retriving BLOB or CLOB data > 32K, does not release locks
properly.   Network Server uses getClob, getBlob to retrieve the data even if the application
uses getCharacteStream, etc, so holds locks to the end of the transaction.
> To reproduce run attached repro
> java LargeDataLocks derbynetclient
> To see the difference with embedded
> java LargeDataLocks derby

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message