[
https://issues.apache.org/jira/browse/DERBY-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Øystein Grøvlen updated DERBY-2892:
-----------------------------------
Kathey Marsden (JIRA) wrote:
>
> Clob and Blob explicitly state that they are valid for the duration
> of the transaction in which they are created.
While I have been aware of this, I have not interpreted this to mean
that the value could not change, just that it should be possible to
use it to access the underlying LOB column. However, I think you
right that in the context of result sets one would expect the LOB
object to represent a LOB value, not a LOB column.
>
> getBinaryStream says:
> "Note: All the data in the returned stream must be read prior to
> getting the value of any other column. The next call to a getter
> method implicitly closes the stream", implying that the stream is
> much shorter lived.
Thank you for making you aware of this. I guess I should have studied
the API doc better. Is the "implicitly closes" part implemented by
Derby? I can not remember to have seen any code for this.
>
> getCharacterStream does not say one way or another, but I assume it
> is parallel with getBinaryStream().
getAsciiStream says the same as getBinaryStream().
>
> Network server does not know the difference between what was called
> in JDBC, getBlob() vs getBinaryStream() vs getBytes() for example.
> Prior to the fix for DERBY-326, Network Server would always call
> getBinaryStream() instead of getBlob and getCharacterStream() rather
> than getClob(). Since the lobs were materialized on the client we
> could still preserve the Blobs and Clobs until the end of the
> transaction. I am not sure how this might be different now with the
> locator work and how changing back to getBinaryStream()
> getCharacterStream() calls would impact that.
With locators all operations in the network server are performed on
Blob/Clob objects. For example, InputStream.read will map to
Blob.getBytes on the server. Hence, I would assume that locks will be
held. I have not checked, but this may now be true even for the
embedded driver. I see two possible solutions to this problem:
1. Change how the locking is done. Maybe one could provide away to
release locks when they are no longer needed.
2. Make a copy of the LOB value and allow concurrent updates. In
10.3 this is now possible since there is a mechanism for making
temporary copies of LOBs. In order for this to be efficient, we
should only make a copy when necessary. Hence, a copy-on-write
mechanism would be useful.
Another thing:
I noticed that in Ole's LOB compatibility testing for 10.3 that the
10.3 version of the BlobClob4BlobTest, a locking test failed when
running a 10.3 client with a 10.1 server (10.3 client with 10.2 server
went OK). Does this mean that the test has been updated to accept
this faulty behavior?
> Closing a resultset after retrieving a large > 32665 bytes value with Network
> Server does not release locks
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2892
> URL: https://issues.apache.org/jira/browse/DERBY-2892
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.2.2.0, 10.3.1.1
> Environment: JDK: build 1.6.0_01-b06 (WinXP & Gentoo/SuSE)
> Hardware: Intel x86
> Client/Server environment
> Reporter: Thomas Niessen
> Priority: Critical
>
> This is the same issue as DERBY-255
> (https://issues.apache.org/jira/browse/DERBY-255). The test attached to
> DERBY-255 shows the locks being not released. Everything is fine when using
> Derby 10.1.3.1 .
> I would think it's a regression bug.
> Output from sysinfo:
> ------------------ Java-Informationen ------------------
> Java-Version: 1.6.0_01
> Java-Anbieter: Sun Microsystems Inc.
> Java-Home: C:\work\applications\development\java\jdk1.6u1-SE\jre
> Java-Klassenpfad:
> C:\work\applications\development\derby-10.2.2.0/lib/derby.jar;C:\work\applications\development\derby-
> 0.2.2.0/lib/derbynet.jar;C:\work\applications\development\derby-10.2.2.0/lib/derbyclient.jar;C:\work\applications\devel
> pment\derby-10.2.2.0/lib/derbytools.jar
> Name des Betriebssystems: Windows XP
> Architektur des Betriebssystems: x86
> Betriebssystemversion: 5.1
> Java-Benutzername: thomas.niessen
> Java-Benutzerausgangsverzeichnis: C:\Dokumente und
> Einstellungen\thomas.niessen
> Java-Benutzerverzeichnis: C:\work\applications\development\derby-10.2.2.0
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.6
> --------- Derby-Informationen --------
> JRE - JDBC: Java SE 6 - JDBC 4.0
> [C:\work\applications\development\derby-10.2.2.0\lib\derby.jar] 10.2.2.0 -
> (485682)
> [C:\work\applications\development\derby-10.2.2.0\lib\derbytools.jar] 10.2.2.0
> - (485682)
> [C:\work\applications\development\derby-10.2.2.0\lib\derbynet.jar] 10.2.2.0 -
> (485682)
> [C:\work\applications\development\derby-10.2.2.0\lib\derbyclient.jar]
> 10.2.2.0 - (485682)
> ------------------------------------------------------
> ----------------- Informationen zur Lõndereinstellung -----------------
> Aktuelle Lõndereinstellung: [Deutsch/Deutschland [de_DE]]
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [cs]
> Version: 10.2.2.0 - (485682)
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [de_DE]
> Version: 10.2.2.0 - (485682)
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [es]
> Version: 10.2.2.0 - (485682)
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [fr]
> Version: 10.2.2.0 - (485682)
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [hu]
> Version: 10.2.2.0 - (485682)
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [it]
> Version: 10.2.2.0 - (485682)
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [ja_JP]
> Version: 10.2.2.0 - (485682)
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [ko_KR]
> Version: 10.2.2.0 - (485682)
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [pl]
> Version: 10.2.2.0 - (485682)
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [pt_BR]
> Version: 10.2.2.0 - (485682)
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [ru]
> Version: 10.2.2.0 - (485682)
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [zh_CN]
> Version: 10.2.2.0 - (485682)
> Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [zh_TW]
> Version: 10.2.2.0 - (485682)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
