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-2892) Closing a resultset after retrieving a large > 32665 bytes value with Network Server does not release locks
Date Tue, 10 Jul 2007 14:02:04 GMT

     [ 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.


Mime
View raw message