[ http://issues.apache.org/jira/browse/DERBY-255?page=all ]
Kathey Marsden updated DERBY-255:
---------------------------------
Attachment: derby255.diff
This fixes DERBY-255
Closing a resultset after retriving BLOB or CLOB data > 32K, does not release
locks properly.
Network server/client materializes the LOB on the client and cannot
differentiate getBlob from getBytes or getBinaryStream. Previously, network
server would always call getBlob/getClob for any lob related call. This change
changes network server to use getBytes/getString and not hold locks for any of
the calls.
The implementation adds a new class EXTDTAInputStream to network server to
localize the stream handling for large objects. This should make it easier to
adjust in the future as improvements are made in the large object handling.
Because we need a length in order to write a stream, EXTDTAInputStream
currently call getBytes or getString to get the length and stream out that
object. This is apparently required because we cannot reset the input stream
after traversing it to get the length.
Future suggestions for changes to network server to handle this in a more
complete way would be to:
1) Change DDMWriter.writeScalarStream to not require a length and optimize
EXTDTAObjectInputStream accordingly
2) Add support for lob locators with network server. The getBlob, getClob
calls would use the locators and would hold locks until the end of the
transaction.
> 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
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Attachments: 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
