[ 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 second.
* 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: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.0.0
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Fix For: 10.1.0.0
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
