db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rhille...@apache.org
Subject svn commit: r488719 [2/2] - in /db/derby/site/trunk: build/site/ build/site/releases/ src/documentation/conf/ src/documentation/content/xdocs/ src/documentation/content/xdocs/releases/
Date Tue, 19 Dec 2006 16:23:11 GMT
Added: db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.2.2.0.html
URL: http://svn.apache.org/viewvc/db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.2.2.0.html?view=auto&rev=488719
==============================================================================
--- db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.2.2.0.html (added)
+++ db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.2.2.0.html Tue
Dec 19 08:23:10 2006
@@ -0,0 +1,1118 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed with
+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to you under the Apache License, Version 2.0
+  (the "License"); you may not use this file except in compliance with
+  the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+-->
+<html> 
+  <header> 
+    <title>Apache Derby 10.2.2.0 Release</title> 
+  </header> 
+  <body>
+  
+    
+    <h1>Distributions</h1>
+    <p>Use the links below to download a distribution of Apache Derby from
+       one of our mirrors. You should <b>always</b> <a href="#Verifying+releases">verify
the integrity</a>
+       of distribution files downloaded from a mirror.</p>
+
+<p>You are currently using <strong>[preferred]</strong>. If you encounter
a
+problem with this mirror, then please select another.  If all
+mirrors are failing, there are backup mirrors at the end of the list.
+See <a href="http://www.apache.org/mirrors/">status</a> of mirrors.
+</p>
+
+<form action="[location]" method="get" id="SelectMirror">
+Other mirrors: <select name="Preferred">
+<!--[if-any http] [for http]-->
+<option value="[http]">[http]</option>
+<!--[end] [end]-->
+<!--[if-any ftp] [for ftp]-->
+<option value="[ftp]">[ftp]</option>
+<!--[end] [end]-->
+<!--[if-any backup] [for backup]-->
+<option value="[backup]">[backup] (backup)</option>
+<!--[end] [end]-->
+</select>
+<input type="submit" value="Change" />     
+</form>
+
+    <p>There are four different distributions:</p>
+    <ul>
+      <li>bin distribution - contains the documentation, javadoc, and jar files for
Derby.</li>
+      <li>lib distribution - contains only the jar files for Derby.</li>
+      <li>lib-debug distribution - contains jar files for Derby with source line numbers.</li>
+      <li>src distribution - contains the Derby source tree at the point which the
binaries were built.</li>
+    </ul>
+    <p> <a href="[preferred]/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-bin.zip">db-derby-10.2.2.0-bin.zip</a>
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-bin.zip.asc">PGP</a>]
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-bin.zip.md5">MD5</a>]<br/>
+    <a href="[preferred]/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-bin.tar.gz">db-derby-10.2.2.0-bin.tar.gz</a>
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-bin.tar.gz.asc">PGP</a>]
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-bin.tar.gz.md5">MD5</a>]</p>
+    
+    <p><a href="[preferred]/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-lib.zip">db-derby-10.2.2.0-lib.zip</a>
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-lib.zip.asc">PGP</a>]
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-lib.zip.md5">MD5</a>]<br/>
+    <a href="[preferred]/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-lib.tar.gz">db-derby-10.2.2.0-lib.tar.gz</a>
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-lib.tar.gz.asc">PGP</a>]
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-lib.tar.gz.md5">MD5</a>]</p>
+    
+    <p><a href="[preferred]/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-lib-debug.zip">db-derby-10.2.2.0-lib-debug.zip</a>
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-lib-debug.zip.asc">PGP</a>]
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-lib-debug.zip.md5">MD5</a>]<br/>
+    <a href="[preferred]/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-lib-debug.tar.gz">db-derby-10.2.2.0-lib-debug.tar.gz</a>
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-lib-debug.tar.gz.asc">PGP</a>]
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-lib-debug.tar.gz.md5">MD5</a>]</p>
+
+    <p><a href="[preferred]/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-src.zip">db-derby-10.2.2.0-src.zip</a>
 [<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-src.zip.asc">PGP</a>]
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-src.zip.md5">MD5</a>]<br/>
+    <a href="[preferred]/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-src.tar.gz">db-derby-10.2.2.0-src.tar.gz</a>
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-src.tar.gz.asc">PGP</a>]
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/db-derby-10.2.2.0-src.tar.gz.md5">MD5</a>]</p>
+    
+    <p>There are two separate Eclipse plugins for Derby:</p>
+    <ul>
+      <li>derby_core_plugin - provides the Derby jar files to other plugins in Eclipse.</li>
+      <li>derby_ui_plugin - provides an Apache Derby Nature in Eclipse for easy database
application development.</li>
+    </ul>
+    <p> <a href="[preferred]/db/derby/db-derby-10.2.2.0/derby_core_plugin_10.2.2.485682.zip">derby_core_plugin_10.2.2.485682.zip</a>
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/derby_core_plugin_10.2.2.485682.zip.asc">PGP</a>]
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/derby_core_plugin_10.2.2.485682.zip.md5">MD5</a>]<br/>
+    <a href="[preferred]/db/derby/db-derby-10.2.2.0/derby_ui_plugin_1.1.0.zip">derby_ui_plugin_1.1.0.zip</a>
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/derby_ui_plugin_1.1.0.zip.asc">PGP</a>]
[<a href="http://www.apache.org/dist/db/derby/db-derby-10.2.2.0/derby_ui_plugin_1.1.0.zip.md5">MD5</a>]</p>
+    <p>Please note: both plugins must be installed for full functionality. For information
on installing and using
+       the Derby plugins for Eclipse, please see the <a href="http://db.apache.org/derby/integrate/plugin_howto.html">Using
the 10.2 Core and 1.1 UI Derby plug-ins</a> page.</p>
+    
+<h1><a name="Release Overview"></a>Release Overview</h1>
+
+<p>
+These notes describe the difference between Derby release 10.2.2.0
+and the preceding release, 10.2.1.6. 10.2.2.0 is a bug-fix release.  It includes compiled
+      versions of Derby's JDBC4 drivers, which appeared in the
+      previous release only as source code.
+In addition, 10.2.2.0 includes a number of
+<a href="#Bug Fixes">bug fixes</a>
+not found in the previous release. No new features appear in 10.2.2.0.
+</p>
+
+<p>
+Derby is a pure Java relational database engine using standard SQL and
+JDBC as its APIs.
+</p>
+
+<p>
+Derby functionality includes:
+</p>
+
+<ul>
+<li>Embedded engine with JDBC drivers</li>
+<li>Network Server</li>
+<li>Network client JDBC drivers</li>
+<li>Command line tools: ij (SQL scripting), dblook (schema dump) and sysinfo (system
info)</li>
+</ul>
+
+<p>
+SQL support:
+</p>
+
+<ul>
+<li>Schemas, tables, temporary tables, views, triggers, indexes, savepoints</li>
+<li>Java procedures and functions</li>
+<li>Standard datatypes including XML, BLOB, and CLOB</li>
+<li>Sub-queries and joins</li>
+<li>Primary key, foreign key, unique and check constraints</li>
+<li>Referential actions</li>
+<li>GRANT/REVOKE support for databases with SQL authorization.</li>
+</ul>
+
+<p>
+Other features:
+</p>
+
+<ul>
+<li>Full ACID transaction support with all four isolation levels</li>
+<li>Row and table level locking</li>
+<li>Configurable authentication including LDAP support</li>
+<li>Import/Export</li>
+<li>On-line backup and recovery support</li>
+<li>Optional on-disk encryption including re-encryption of existing encrypted databases</li>
+<li>Platform independent database format</li>
+<li>Full support for Java 2 Security Manager</li>
+</ul>
+
+<p>
+JDK/JDBC support:
+</p>
+
+<ul>
+<li>JDKs 1.3, 1.4, 1.5, and 1.6 plus J2ME J2ME/CDC/Foundation Profile</li>
+<li>JSR-169, JDBC 2.1, JDBC 3.0, and JDBC 4.0 support</li>
+</ul>
+
+<h1><a name="New Features"></a>New Features</h1>
+
+<p>
+Release 10.2.2.0 is a bug-fix release. No new features were added
+      since 10.2.1.6.
+</p>
+
+<h1><a name="Bug Fixes"></a>Bug Fixes</h1>
+
+<p>
+The following bug fixes turn up
+in Derby 10.2.2.0 but not in the preceding 10.2.1.6 release.
+</p>
+
+<TABLE border="2">
+  <TBODY>
+    <TR>
+      <TD><b>Issue Id</b></TD>
+      <TD><b>Description</b></TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-638">DERBY-638</a></TD>
+      <TD> Network driver setTransactionIsolation() causes a commit, but does not complete
it locally</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-737">DERBY-737</a></TD>
+      <TD> SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not
exist</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-912">DERBY-912</a></TD>
+      <TD> OutOfMemory error on continuous execution of SQL statement</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1089">DERBY-1089</a></TD>
+      <TD>  Derby fails inserting a join into a table with a generated column</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1204">DERBY-1204</a></TD>
+      <TD>  CREATE TRIGGER with an INSERT action statement with multiple rows and a
referenced column throws a StringIndexOutOfBoundsException</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1231">DERBY-1231</a></TD>
+      <TD>  LIKE does not match empty strings when used with a prepared statement</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1495">DERBY-1495</a></TD>
+      <TD> Attempt to modify an identity column error after resetting identity column</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1645">DERBY-1645</a></TD>
+      <TD> ALTER TABLE ... SET INCREMENT BY X... Turns off the "Generated By Default"
identity column constraint</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1693">DERBY-1693</a></TD>
+      <TD> Out of Memory Error with derby.language.logStatementText=true</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1716">DERBY-1716</a></TD>
+      <TD> Revoking select privilege from a user times out when that user still have
a cursor open.</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1732">DERBY-1732</a></TD>
+      <TD> The language and store systems treat a JVM error such as OutOfMemoryError
differently leading to the raw store protocol violation errors</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1847">DERBY-1847</a></TD>
+      <TD> SELECT statement asserts with XJ001 when attempted to select a newly added
column in SQL authorization mode</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1856">DERBY-1856</a></TD>
+      <TD> Multiple communication failures when starting server with derby.drda.timeSlice</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1894">DERBY-1894</a></TD>
+      <TD> SQLSTATE 42X10 occurs when qualifying a column with a synonym in ORDER BY
clause</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1940">DERBY-1940</a></TD>
+      <TD> Removed Ease of Development API</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1967">DERBY-1967</a></TD>
+      <TD> UNION (ALL) constraint violation problem</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-1991">DERBY-1991</a></TD>
+      <TD> Misleading stack traces for exceptions raised by the JDBC 4.0 embedded driver</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-2008">DERBY-2008</a></TD>
+      <TD>  NullPointerException with LTRIM, RTRIM and 2-argument SUBSTR() call in
GROUP BY clause.</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-2014">DERBY-2014</a></TD>
+      <TD> NullPointerException with NULLIF in GROUP BY clause</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-2015">DERBY-2015</a></TD>
+      <TD> NullPointerException in INSERT ... SELECT with self-joined table and IDENTITY
column</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-2030">DERBY-2030</a></TD>
+      <TD> 'set schema sys' followed by 'show tables' does not show tables in sys schema</TD>
+    </TR>
+    <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-2084">DERBY-2084</a></TD>
+      <TD>  getTransactionIsolation() in network client should not activate a transaction</TD>
+    </TR>
+     <TR>
+      <TD><a href="http://issues.apache.org/jira/browse/DERBY-2131">DERBY-2131</a></TD>
+      <TD>  External DTD files are accessed without a privileged block when Derby parses
XML values that reference such DTDs.</TD>
+    </TR>
+  </TBODY>
+</TABLE>
+
+<h1><a name="Issues"></a>Issues</h1>
+
+<p>
+Applications which run against Derby 10.0 or 10.1 may rely on
+      incorrect Derby behavior. After upgrading to 10.2, those
+      applications may need some recoding so that they no longer rely
+      on bad behavior which has been fixed. Please consult the
+      following list of issues which may require some application recoding.
+Note that 10.2.2.0 does not introduce any additional issues beyond the
+      issues introduced by 10.2.1.6:
+</p>
+
+<hr/>
+<h2>
+DERBY-253
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-253">DERBY-253</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+PreparedStatement.setUnicodeStream() and ResultSet.getUnicodeStream()
+throw SQLException when invoked after upgrading to Apache Derby 10.2.
+</p>
+
+<p><b>Symptoms</b></p>
+<p>
+Calling either of these methods will result in an exception with
+SQLSTATE 0A000 and message: "Feature not implemented: ..."
+</p>
+
+<p><b>Cause</b></p>
+<p>
+PreparedStatement.setUnicodeStream() and ResultSet.getUnicodeStream()
+have been deprecated since JDBC 2.0. Derby's implemetation of these
+methods was broken, and it was decided that the methods should throw a
+not-implemented exception instead of being fixed.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+This was an intentional change. No Derby product solution is offered.
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+Use setCharacterStream() and getCharacterStream() instead of
+setUnicodeStream() and getUnicodeStream().
+</p>
+
+
+
+<hr/>
+<h2>
+DERBY-668
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-668">DERBY-668</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+Sysinfo needs special permissions when run under a Java security manager.
+</p>
+
+<p><b>Symptoms</b></p>
+<p>
+If you do not provide these permissions, you will see a message such as the following in
your sysinfo output: Unable to analyze class path: access denied (java.util.PropertyPermission
java.class.path read).
+</p>
+
+<p><b>Cause</b></p>
+<p>
+Such a message does not indicate an error; it simply means that the sysinfo tool was unable
to provide detailed classpath information because it did not have permission to read the classpath.
In prior releases, under these circumstances, sysinfo would silently print nothing, now it
prints an informational message about the reason that it couldn't provide any classpath information.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+The sysinfo tool now prints additional information about the
+origin of the classes and jars that it examines. The origin
+of a class might be: an entry in the application classpath,
+an entry in a class loader location
+list, a jar fetched due to being listed in the manifest entry
+of another jar, a standard extension in the JRE's extensions
+directory, a jar installed into the application server,
+or any of various other possibilities.
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+Grant these permissions so that sysinfo can run correctly under the
+        Java security manager.
+</p>
+
+<hr/>
+<h2>
+DERBY-721
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-721">DERBY-721</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+Behavior has changed for applications which open two InputStreams on the
+          same ResultSet column.
+</p>
+
+<p><b>Symptoms</b></p>
+<p>
+Undefined results were returned to an application which
+opened an InputStream twice on the same column of a ResultSet.
+The value siphoned out of the column was erratic.
+</p>
+
+<p><b>Cause</b></p>
+<p>
+Streams were being shared between the two readers.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+Now we throw an exception if the application tries to open
+two streams on the same column in a ResultSet.
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+Users must recode Applications which open
+ multiple streams on the same column.
+</p>
+
+
+<hr/>
+<h2>
+DERBY-781
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-781">DERBY-781</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+Compilation times may increase for queries which have subqueries in
+        the FROM clause.
+</p>
+
+<p><b>Symptoms</b></p>
+<p>
+Execution performance of queries containing non-flattenable subqueries may change. The expectation
is that the new (10.2) query plans will show improved performance over the old ones.
+</p>
+<p>
+Another potential symptom is that the compilation time for such queries may increase. If
this happens, the increase should only occur at compilation time; execution time should either
improve or, at the very least, remain the same as in earlier versions of Derby.
+</p>
+
+<p><b>Cause</b></p>
+<p>
+If the optimizer chooses to do a hash join with a subquery, Derby only has to execute the
subquery a single time per statement, after which Derby can just perform the desired join
against the materialized result set. Depending on how many rows are in the outer table of
the join, this once-per-statement execution of the subquery can lead to major performance
improvements over the once-per-outer-row execution employed by earlier versions of Derby.
+</p>
+<p>
+As for the extra compilation time, this is due to the simple fact that the optimizer is now
doing more work--i.e. in addition to considering nested loop joins with subqueries, it is
now _also_ considering hash joins with those subqueries, and that means that it could potentially
take longer for the optimizer to finish its work. Note again that, if it occurs, the increased
time should only occur at compilation time; execution time should either improve or, at the
very least, remain the same as in earlier versions of Derby.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+This was an intentional change to improve the execution plans chosen by the optimizer for
queries having large and/or complex subqueries. The expectation is that the new behavior--and
the subsequent query plans--will lead to improved performance over the old ones, so no further
solution is required.
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+There is no way to disable/workaround this new behavior. The increased
+        compilation time buys better performance at query execution time.
+</p>
+<p>
+That said, any user who notices a negative performance change after
+moving to Derby 10.2, and who believes that the difference in
+performance is related to this optimizer enhancement, is encouraged to
+visit the
+<a href="http://wiki.apache.org/db-derby/PerformanceDiagnosisTips">performance diagnosis
page</a>
+and to follow up with his/her findings on the Derby mailing lists.
+</p>
+
+
+
+<hr/>
+<h2>
+DERBY-822
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-822">DERBY-822</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+Queries may fail earlier and locks may be acquired earlier when
+executing queries. Location where errors occur in an embedded
+environment is different from the location where errors occur in a
+network environment.
+</p>
+
+<p><b>Symptoms</b></p>
+<p>
+Errors that happen as part of the normal execution path are moved earlier. For example, code
to execute a query, with executeQuery() retrieve the result set metadata and then perform
a next() might fail with a lock timeout on executeQuery() instead of next(). Locking changes
are observed.
+</p>
+
+<p><b>Cause</b></p>
+<p>
+Pre-fetching moves execution of retrieval of data earlier for network client/server configurations.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+This was an intentional behavior change to improve performance. No Derby product solution
is offered.
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+Application code needs to be changed to adjust error handling if
+needed. 
+</p>
+
+
+
+<hr/>
+<h2>
+DERBY-1130
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-1130">DERBY-1130</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+When using Derby's client DataSources, you can no longer set the database name using
+          setConnectionAttributes().
+</p>
+
+<p><b>Symptoms</b></p>
+<p>
+Derby's client DataSources were using a wrong database name when
+getting a connection in the following case:
+</p>
+
+<ul>
+<li>databaseName is not set as a Derby DataSource property</li>
+<li>databaseName is set as a connection attribute using
+setConnectionAttributes method</li>
+</ul>
+
+<p><b>Cause</b></p>
+<p>
+Instead of throwing an exception saying databaseName is a required Derby DataSource property
and must be set, client driver was using "null" as database name and returning a connection
to database named "null".
+The database name was constructed wrongly in the client driver.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+This was solved by setting the internal database name property in the client driver correctly.
Also ensured that databaseName set as a connection attribute will not be used by Derby's client
DataSources.. This fix will be available in Derby versions 10.2 and above.
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+When upgrading an application to run against Derby 10.2, make sure the
+        database name is set
+only as a DataSource property when using Derby's client DataSources.
+</p>
+
+<hr/>
+<h2>
+DERBY-1295
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-1295">DERBY-1295</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+Result sets of type TYPE_SCROLL_INSENSITIVE no longer implicitly close
+when positioned at the end in autocommit mode.
+</p>
+</ul>
+
+<p><b>Symptoms</b></p>
+<p>
+Calling the ResultSet.next() method when positioned on the last row of
+a result set of type SCROLL_INSENSITIVE in auto commit mode used to cause the result set
to be closed.
+</p>
+
+<p><b>Cause</b></p>
+<p>
+The JDBC specification allows a JDBC driver to implicitly close a
+ResultSet when the ResultSet type is TYPE_FORWARD_ONLY and the next
+method of ResultSet returns false. Derby also used to implicitly close result sets of type
SCROLL_INSENSITIVE when the ResultSet.next() method returns false in auto commit mode.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+The behavior of SCROLL_INSENSITIVE result sets in auto commit mode has
+been changed to comply with the JDBC4
+specification. SCROLL_INSENSITIVE result sets are not implicitly
+closed when calling the ResultSet.next() method in auto commit mode
+while positioned on the last row. 
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+Fix applications which rely on the previous, non-standard behavior.
+</p>
+
+
+<hr/>
+<h2>
+DERBY-1314
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-1314">DERBY-1314</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+The return values of executeQuery() and executeUpdate() have changed
+            for the Derby network client.
+</p>
+
+<p><b>Symptoms</b></p>
+<p>
+The behaviour of executeQuery() and executeUpdate() did not match the
+JDBC specification when invoking stored procedures.
+</p>
+<ul>
+<li> When invoking a stored procedure with executeQuery() or
+    executeUpdate(), an exception was thrown indicating that the
+    procedure did not return the correct number of ResultSet objects,
+    although the correct number of ResultSet objects was in fact
+    returned.
+</li>
+<li> When invoking a stored procedure with executeQuery() or
+    executeUpdate(), and the procedure did not return the correct
+    number of ResultSet objects, the query executed successfully.
+</li>
+<li> With the network client driver, when invoking a stored procedure
+    with executeUpdate(), the return value was -1, whereas the JDBC
+    specification says it should be 0.
+</li>
+</ul>
+
+<p><b>Cause</b></p>
+<p>
+The methods executeQuery() and executeUpdate() were not implemented in
+compliance with the JDBC specification.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+In Derby 10.2, the behaviour of the methods executeQuery() and
+executeUpdate() has been changed to match the JDBC specification.
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+Use execute() instead of executeUpdate()/executeQuery() to invoke a
+stored procedure which does not return exactly 0 or 1 ResultSet
+objects.
+</p>
+
+
+<hr/>
+<h2>
+DERBY-1323
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-1323">DERBY-1323</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+Calls to rowUpdated(), rowDeleted(), and rowInserted() now forbidden
+on unpositioned, forward-only ResultSets.
+</p>
+
+<p><b>Symptoms</b></p>
+<p>
+For a JDBC ResultSet with type TYPE_FORWARD_ONLY, the methods
+rowUpdated, rowDeleted and rowInserted could previously be called
+while not on a row, i.e. before positioning in the result set, while
+on insertRow, after updateRow before new positioning, after deleteRow
+before new positioning and when after last row. This is now
+disallowed.
+</p>
+<p>
+Calls to any of these methods while not on a row will now throw
+SQLException with SQLState 24000.
+</p>
+
+<p><b>Cause</b></p>
+<p>
+Derby now disallows these calls when not on a row.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+Change the application to not call these methods unless on a row. Note
+that using them at all is rather meaningless for a ResultSet of type
+TYPE_FORWARD_ONLY since the returned result will always be 'false'.
+This is because once you modify a row, it can no longer be accessed,
+you need to move to the next row, if there is one, to get a new
+current row. Presently in Derby, these methods are only really
+meaningfully used for result sets of type TYPE_SCROLL_INSENSITIVE and
+of concurrency CONCUR_UPDATABLE in which case updated and deleted rows
+can be detected.
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+Fix applications which rely on this non-standard behavior.
+</p>
+
+
+
+<hr/>
+<h2>
+DERBY-1357
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-1357">DERBY-1357</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+Performance may change for queries with nested subqueries and/or large
+        FROM clauses.
+</p>
+
+<p><b>Symptoms</b></p>
+<p>
+Execution performance of large queries (esp. those with nested subqueries and/or with large
FROM clauses) may change. The expectation is that the new (10.2) query plans will show improved
performance over the old ones.
+</p>
+
+<p><b>Cause</b></p>
+<p>
+Since the optimizer is now spending less time evaluating sub-optimal join orders, it is possible
that it will be able to try out more join orders before optimizer "timeout" occurs. As a result
the optimizer can sometimes find better plans than it did in earlier versions of Derby.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+This was an intentional change to fix behavior that was not working correctly in earlier
versions of Derby. The expectation is that the new behavior--and the subsequent query plans--will
lead to improved performance over the old ones, so no further solution is required.
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+In general, the performance of these queries should stay the same or
+        improve. However, it is possible that performance may degrade
+        for some queries.
+Any user who notices a negative performance change after
+moving to Derby 10.2, and who believes that the difference in
+performance is related to this optimizer change, is encouraged to
+visit the
+<a href="http://wiki.apache.org/db-derby/PerformanceDiagnosisTips">performance diagnosis
page</a>
+and to follow up with his/her findings on the Derby mailing lists.
+</p>
+
+<hr/>
+<h2>
+DERBY-1384
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-1384">DERBY-1384</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+Maximum BLOB/CLOB length has increased to 2G-1.
+</p>
+</ul>
+
+<p><b>Symptoms</b></p>
+<p>
+Previously, Derby rejected BLOB lengths greater than 1M.
+</p>
+
+<p><b>Cause</b></p>
+<p>
+The allowable size of Derby LOBs has been increased.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+This was an intentional change to make Derby conform to its own
+documentation.
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+Fix applications which rely on Derby rejecting LOBs that are bigger
+than 1M.
+</p>
+
+
+
+<hr/>
+<h2>
+DERBY-1652
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-1652">DERBY-1652</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+Recursive trigger firing disallowed.
+</p>
+
+<p><b>Symptoms</b></p>
+<p>
+In some cases, an after update trigger does not get fired upon itself when its trigger action
contains
+an update statement on the trigger's subject table.
+</p>
+<p>
+(1) When defining a trigger for the first time for a table, e.g.:
+</p>
+
+<pre>  
+        CREATE TABLE "TEST" ("TESTID" INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START
WITH 1, INCREMENT BY 1),
+                             "INFO" INTEGER NOT NULL,
+                             "TIMESTAMP" TIMESTAMP NOT NULL DEFAULT '1980-01-01-00.00.00.000000');
+    
+        CREATE TRIGGER UPDATE_TEST
+        AFTER UPDATE ON TEST
+        REFERENCING OLD AS OLD
+        FOR EACH ROW MODE DB2SQL
+            UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID;
+  
+        INSERT INTO TEST (INFO) VALUES (1), (2), (3);
+
+        UPDATE TEST SET INFO = 1 WHERE TESTID = 2;
+</pre>
+
+
+<p>
+The above update statement executes successfully which it is incorrect. The system should
have issued
+SQLSTATE 54038 since it self-triggers to its maximum depth of 16.
+</p>
+
+   
+<p>
+(2) With the above example, when an user upgrades to a higher version and issues the same
update statement:
+</p>
+
+<pre>
+        UPDATE TEST SET INFO = 1 WHERE TESTID = 2;
+        ERROR 54038: Maximum depth of nested triggers was exceeded.
+</pre>
+
+<p>
+The SQLSTATE 54038 is issued in this case because after database upgrade, the trigger action
will be
+invalidated by the system and will force a recompilation of the trigger when it is fired.
The system
+generates the correct execution plan this time and since the trigger behavior have changed,
this might
+cause applications to break unexpectedly.
+</p>
+
+<p><b>Cause</b></p>
+<p>
+Derby did not generate the correct execution plan for self-trigger invocation when such a
trigger is declared
+for the first time on the subject table; hence, resulting in the stated problem above. The
affected version is
+Derby 10.0 and 10.1.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+This behavior has been corrected in 10.2.
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+If self-trigger invocation was not intended by the application, the application can select
which column(s) on the
+update statement can cause the trigger to fire in the CREATE TRIGGER statement. i.e.:
+</p>
+
+<pre>
+   CREATE TRIGGER update_test
+   AFTER UPDATE OF INFO ON test
+   REFERENCING OLD AS old
+   FOR EACH ROW MODE DB2SQL
+       UPDATE test SET timestamp=current_timestamp WHERE testid=old.testid;
+</pre>
+ 
+<p>
+In the above statement, the trigger will only fire when an update
+is made to the "info" column instead of any column(s). 
+</p>
+
+
+<hr/>
+<h2>
+DERBY-1867
+</h2>
+<p>
+See
+<a href="http://issues.apache.org/jira/browse/DERBY-1867">DERBY-1867</a>.
+</p>
+<p><b>Problem</b></p>
+<p>
+With IBM 1.4.1 JVM, trying to connect to the server using the derby client with security
mechanism 8 (USRSSSBPWD) will result in error.
+</p>
+</ul>
+
+<p><b>Symptoms</b></p>
+<p>
+Connecting using the client driver with security mechanism 8 will throw the following error
+ERROR XJ112: Security exception encountered, see next exception for details.
+The stack trace will show that the problem is caused by java.security.NoSuchAlgorithmException:
SHA1PRNG SecureRandom not available
+</p>
+
+<p><b>Cause</b></p>
+<p>
+Current USRSSBPWD implementation uses SHA1PRNG algorithm to generate random number(seed)
that gets exchanged between client and the server. The SHA1PRNG algorithm is not available
with the JCE provider that comes with IBM JVM version 1.4.1.
+</p>
+
+<p><b>Solution</b></p>
+<p>
+You must use another JCE provider.
+</p>
+
+<p><b>Workaround</b></p>
+<p>
+If you need to use the security mechanism 8, then make sure that support for SHA1PRNG is
available in the JCE provider that is available with a particular JVM.
+For e.g. Use IBM 1.4.2 JVM that has support for SHA1PRNG or the Sun JVMs.
+</p>
+
+
+<h1><a name="Build Environment"></a>Build Environment</h1>
+
+<p>
+Derby release 10.2.2.0 was built using the following environment:
+</p>
+
+<ul>
+<li><b>Branch</b> - Source code came from the 10.2 branch.</li>
+<li><b>Machine</b> - SunOS 5.11 snv_48.</li>
+<li><b>Ant</b> - Apache Ant version 1.6.5 compiled on June 2 2005.</li>
+<li><b>JDK 1.3</b> - Java(TM) 2 Runtime Environment, Standard Edition (build
1.3.1_19-b03).</li>
+<li><b>JDK 1.4</b> - Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.2_12-b03).</li>
+<li><b>JDK 1.6</b> - Java(TM) 2 Runtime Environment, Standard Edition (build
1.6.0-b105).</li>
+<li><b>OSGi</b> - The osgi.jar was used to build org.apache.derby.osgi.EmbeddedActivator.</li>
+<li><b>Compiler</b> - The 1.4.2_12-b03 javac was used to compile all
+        classes except for the JDBC4 drivers. The JDBC4 driver classes were compiled
+        using the 1.6.0-b105 javac.</li>
+<li><b>JSR 169</b> - J2ME support was built using java.sun.com/j2me (j2me_cdc_fp-1_0_2).</li>
+</ul>
+
+        
+ 
+    <h1>Testing</h1>
+ 
+    <p>Tests were run on the following platforms. Results are listed separately for
each platform.</p>
+    
+    <table>
+      <tr>
+        <td>Type test</td>
+        <td>platform, jvm version</td>
+        <td>by:</td>
+      </tr>
+      <tr>
+        <td>derbyall suite</td>
+        <td>Solaris 10 x86 machine using Sun's JDK 1.5.0_07</td>
+        <td>John Embretsen</td>
+      </tr>
+       <tr>
+        <td>derbyall suite</td>
+        <td> SunOS 5.11 snv_48 using Sun 1.4.2_12-b03 and 1.6.0-b105</td>
+        <td>Rick Hillegas</td>
+      </tr>
+       <tr>
+        <td>derbyall suite</td>
+        <td>Ubuntu 5.10 on i386 using JDK 1.5.0_06 and 1.6.0</td>
+        <td>Bernt Johnsen</td>
+      </tr>
+      <tr>
+        <td>derbyall suite</td>
+        <td>SLES 10  - Kernel 2.6.16.21-0.25-bigsmp (0) and  IBM15 (SR3) and IBM 142
(SR7)</td>
+        <td>Rajesh Kartha</td>
+      </tr>
+      <tr>
+        <td>derbyall suite</td>
+        <td>RHEL 4.0 - Kernel 2.6.9-42.0.3.ELsmp and IBM142 (SR7)</td>
+        <td>Rajesh Kartha</td>
+      </tr>
+      <tr>
+        <td>derbyall suite</td>
+        <td>AIX 5.3 with IBM15(SR3),
+AIX 5.3 with IBM142(SR5),
+zOS with IBM15(SR3),
+zOS with IBM142(SR5)</td>
+        <td>Manjula Kutty</td>
+      </tr>
+      <tr>
+        <td>derbyall suite</td>
+        <td>Windows XP Pro</td>
+        <td>Yip Ng</td>
+      </tr>
+      <tr>
+        <td>derbyall suite</td>
+        <td>HP-UX v1.11 i with HPs SDK 1.5.0.03</td>
+        <td>Vemund Ostgaard</td>
+      </tr>
+      <tr>
+        <td>derbyall suite</td>
+        <td>Ubuntu 6.06 (Linux)</td>
+        <td>Olav Sandstaa</td>
+      </tr>
+      <tr>
+        <td>derbyall suite</td>
+        <td>Extensive platform testing. See
+          <a href="http://wiki.apache.org/db-derby/TenTwoPlatformTesting">10.2 Platform
Testing</a>.</td>
+        <td>Henri van de Scheur</td>
+      </tr>
+      <tr>
+        <td>derbyall suite</td>
+        <td>Solaris 10 x86 machine using Sun's JDK 1.5</td>
+        <td>Dag Wanvik</td>
+      </tr>
+      <tr>
+        <td>Compatibility tests</td>
+        <td>-</td>
+        <td>Ole Solberg</td>
+      </tr>
+      <tr>
+        <td>Distribution contents verified</td>
+        <td>-</td>
+        <td>Andrew McIntyre</td>
+      </tr>
+      <tr>
+        <td>Eclipse plugins on eclipse 3.2.1, embedded and client jdbc
+        drivers</td>
+        <td>-</td>
+        <td>Jean Andersen</td>
+      </tr>
+      <tr>
+        <td>index.html links verified</td>
+        <td>-</td>
+        <td>Rick Hillegas</td>
+      </tr>
+      <tr>
+        <td>Large data volume tests</td>
+        <td>See
+          <a href="http://dbtg.thresher.com/derby/test/10.2.2.0_RC/AdditionalTests.html">Additional
Tests</a></td>
+          and
+          <a href="http://dbtg.thresher.com/derby/test/10.2.2.0_RC/jvm1.6/testing/Limited/testSummary-485682.html"></a>Test
Summary.</td>
+        </td>
+        <td>Ole Solberg</td>
+      </tr>
+      <tr>
+        <td>Long-running DOTS test</td>
+        <td>olaris 10 x86 machine using Sun's JDK 1.5.0_07</td>
+        <td>John Embretsen</td>
+      </tr>
+      <tr>
+        <td>Long-running tests</td>
+        <td>-</td>
+        <td>Rajesh Kartha</td>
+      </tr>
+      <tr>
+        <td>ODBC tests</td>
+        <td>DB2 Runtime Client (v8)</td>
+        <td>Army Brown</td>
+      </tr>
+      <tr>
+      <tr>
+        <td>Order entry benchmark</td>
+        <td>Order entry benchmark (see derby-1987)  for a scale of 10 using bulk insert
on RedHat linux/ibm142</td>
+        <td>Sunitha Kambhampati</td>
+      </tr>
+      <tr>
+        <td>Scripts verified</td>
+        <td>Windows, Linux</td>
+        <td>Rajesh Kartha</td>
+      </tr>
+      <tr>
+        <td>Signatures verified</td>
+        <td>-</td>
+        <td>Andrew McIntyre</td>
+      </tr>
+      <tr>
+        <td>XMLSuite</td>
+        <td>IBM142</td>
+        <td>Army Brown</td>
+      </tr>
+    </table>
+
+	
+
+
+	
+
+<p>
+Several test issues were reported, such as
+<a href="http://issues.apache.org/jira/browse/DERBY-937">DERBY-937</a>(1.5),
+<a href="http://issues.apache.org/jira/browse/DERBY-1585">DERBY-1585</a>(1.5,
1.6),
+<a href="http://issues.apache.org/jira/browse/DERBY-1947">DERBY-1947</a>,
+<a href="http://issues.apache.org/jira/browse/DERBY-2177">DERBY-2177</a>,
+<a href="http://issues.apache.org/jira/browse/DERBY-2178">DERBY-2178</a>,
+<a href="http://issues.apache.org/jira/browse/DERBY-2180">DERBY-2180</a>,
+However, none of these issues was considered a blocker for the release.
+</p>
+    
+    <p>Tests for a specific platform can be run using the derbyTesting.jar file that
can be found in the lib directory of the -lib or -bin distributions.</p>
+    
+    <p>Instructions on how to run the tests can be found in the <a href="http://svn.apache.org/repos/asf/db/derby/code/branches/10.2/java/testing/README.htm">testing
README</a>.</p>
+
+
+ 
+
+<h1><anchor id="Verifying+releases"/>Verifying releases</h1>
+
+<p>It is essential that you verify the integrity of the downloaded
+files using the PGP and MD5 signatures.  MD5 verification ensures the
+file was not corrupted during the download process.  PGP verification
+ensures that the file came from a certain person.</p>
+
+<p>The PGP signatures can be verified using
+<a href="http://www.pgpi.org/">PGP</a> or
+<a href="http://www.gnupg.org/">GPG</a>.
+First download the Apache Derby
+<a href="http://svn.apache.org/repos/asf/db/derby/code/trunk/KEYS">KEYS</a>
+as well as the <code>asc</code> signature file for the particular
+distribution. It is important that you get these files from the ultimate
+trusted source - the main ASF distribution site, rather than from a mirror.
+Then verify the signatures using ...</p>
+
+<pre>
+% pgpk -a KEYS
+% pgpv db-derby-X.Y.tar.gz.asc
+
+<em>or</em>
+
+% pgp -ka KEYS
+% pgp db-derby-X.Y.tar.gz.asc
+
+<em>or</em>
+
+% gpg --import KEYS
+% gpg --verify db-derby-X.Y.tar.gz.asc
+
+</pre>
+
+<p>To verify the MD5 signature on the files, you need to use a program
+called <code>md5</code> or <code>md5sum</code>, which is
+included in many unix distributions.  It is also available as part of
+<a href="http://www.gnu.org/software/textutils/textutils.html">GNU
+Textutils</a>.  Windows users can get binary md5 programs from <a
+href="http://www.fourmilab.ch/md5/">here</a>, <a
+href="http://www.pc-tools.net/win32/freeware/console/">here</a>, or
+<a href="http://www.slavasoft.com/fsum/">here</a>.</p>
+
+<p>We strongly recommend you verify your downloads with both PGP and MD5.</p>
+ 
+    
+  </body>
+</html>

Propchange: db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.2.2.0.html
------------------------------------------------------------------------------
    svn:eol-style = native



Mime
View raw message