[
https://issues.apache.org/jira/browse/DERBY-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512479
]
Kathey Marsden commented on DERBY-2892:
---------------------------------------
Well deferring the opening of the stream until it is time to write the EXTDTA
will not work because we need to know whether the value is null when we send
the QRYDTA. So I guess its back to the drawing board. I don't have any good
ideas for a fix at this point. The 10.1 solution was to read the whole lob
into memory. I don't think we want to return to that for 10.2. Oystein had
mentioned the possibility of changing the locking behavior as a solution, but I
am way out of my league in that area so won't pursue that for 10.2. Hopefully
if it is changed for 10.3, we can backport the fix.
Oystein mentioned two possibilities for 10.3
1. Change how the locking is done. Maybe one could provide away to
release locks when they are no longer needed.
By this do you mean to release the locks when the LOB is no longer referenced?
That sounds good, but may still cause issues if the garbage collector has not
kicked in, but perhaps would be suitable for backport to 10.2
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.
This sounds ok too but does not offer any solution for 10.2, so I guess I would
prefer 1.
> 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
> Attachments: DERBY-2892_07_10_07_try1_diff.txt,
> DERBY-2892_07_10_07_try1_stat.txt, protocolErrorRepro.zip
>
>
> 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.
