You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by rh...@apache.org on 2006/12/05 23:44:50 UTC
svn commit: r482813 - /db/derby/code/branches/10.2/RELEASE-NOTES.html
Author: rhillegas
Date: Tue Dec 5 14:44:48 2006
New Revision: 482813
URL: http://svn.apache.org/viewvc?view=rev&rev=482813
Log:
DERBY-2129: Add empty section for New Features and copy Issues section from 10.2.1.6 release notes.
Modified:
db/derby/code/branches/10.2/RELEASE-NOTES.html
Modified: db/derby/code/branches/10.2/RELEASE-NOTES.html
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.2/RELEASE-NOTES.html?view=diff&rev=482813&r1=482812&r2=482813
==============================================================================
--- db/derby/code/branches/10.2/RELEASE-NOTES.html (original)
+++ db/derby/code/branches/10.2/RELEASE-NOTES.html Tue Dec 5 14:44:48 2006
@@ -5,7 +5,9 @@
<ul>
<li><a href="#Overview">Overview</a></li>
+<li><a href="#New Features">New Features</a></li>
<li><a href="#Bug Fixes">Bug Fixes</a></li>
+<li><a href="#Issues">Issues</a></li>
<li><a href="#Build Environment">Build Environment</a></li>
</ul>
@@ -75,6 +77,13 @@
<li>JSR-169, JDBC 2.1, JDBC 3.0, and JDBC 4.0 support</li>
</ul>
+<h2><a name="New Features"></a>New Features</h2>
+
+<p>
+Release 10.2.2.0 is a bug-fix release. No new features were added
+ since 10.2.1.6.
+</p>
+
<h2><a name="Bug Fixes"></a>Bug Fixes</h2>
<p>
@@ -166,6 +175,845 @@
</TR>
</TBODY>
</TABLE>
+
+<h2><a name="Issues"></a>Issues</h2>
+
+<p>
+10.2.2.0 does not introduce any additional issues beyond the 10.2.1.6 issues.
+ Those issues are:
+</p>
+
+<ul>
+<li><a href="#253">253</a> - Client should throw not implemented exception for depricated setUnicodeStream/getUnicodeStream</li>
+<li><a href="#668">668</a> - SysInfo does not print the right information when Derby is not loaded through the classpath.</li>
+<li><a href="#721">721</a> - State of InputStream retrieved from resultset is not clean , if there exists previous InputStream .</li>
+<li><a href="#781">781</a> - Materialize subqueries in select list where possible to avoid creating invariant resultsets many times.</li>
+<li><a href="#822">822</a> - Client driver: Pre-fetch data on executeQuery()</li>
+<li><a href="#1130">1130</a> - Client should not allow databaseName to be set with setConnectionAttributes</li>
+<li><a href="#1295">1295</a> - Result sets of type TYPE_SCROLL_INSENSITIVE should not implicitly close due to positioning in autocommit mode</li>
+<li><a href="#1314">1314</a> - Differences between client and embedded when invoking stored procedures using Statement.executeUpdate()</li>
+<li><a href="#1323">1323</a> - Detectability methods rowUpdated, rowInserted, rowDeleted can be called from illegal states in both clients</li>
+<li><a href="#1357">1357</a> - Short-circuit logic in optimizer appears to be incorrect...</li>
+<li><a href="#1384">1384</a> - Increase default BLOB/CLOB length to maximum supported (2G?)</li>
+<li><a href="#1621">1621</a> - Trigger action statement is not recompile when there is a change that would affect it.</li>
+<li><a href="#1652">1652</a> - Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: "Maximum depth of nested triggers was exceeded" as it should</li>
+<li><a href="#1867">1867</a> - Document algorithm support required for using secmec 8(USRSSSBPWD) and limitation on ibm141 vm.</li>
+</ul>
+
+<hr/>
+<blockquote>
+<h3>
+<a name="253"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-253">DERBY-253</a>
+</h3>
+<h4>Problem</h4>
+<p>
+PreparedStatement.setUnicodeStream() and ResultSet.getUnicodeStream()
+throw SQLException when invoked after upgrading to Apache Derby 10.2.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<p>
+Calling either of these methods will result in an exception with
+SQLSTATE 0A000 and message: "Feature not implemented: ..."
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<p>
+This was an intentional change. No Derby product solution is offered.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<p>
+Use setCharacterStream() and getCharacterStream() instead of
+setUnicodeStream() and getUnicodeStream().
+</p>
+</blockquote>
+
+
+
+<hr/>
+<blockquote>
+<h3>
+<a name="668"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-668">DERBY-668</a>
+</h3>
+<h4>Problem</h4>
+<p>
+Sysinfo classpath information was insufficiently detailed.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<p>
+Sometimes it was hard to tell where the Derby classes were actually being loaded from in the JVM.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<p>
+The algorithm that sysinfo used for analyzing and reporting on the application classpath was not robust.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<p>
+No workaround. The behavior is now correct.
+</p>
+</blockquote>
+
+<hr/>
+<blockquote>
+<h3>
+<a name="721"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-721">DERBY-721</a>
+</h3>
+<h4>Problem</h4>
+<p>
+Undefined results were returned to an application which
+opend an InputStream twice on the same column of a ResultSet.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<p>
+The value siphoned out of the column was erratic.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<p>
+Streams were being shared between the two readers.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<p>
+Now we throw an exception if the application tries to open
+two streams on the same column in a ResultSet.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<p>
+Users must recode Applications which open
+ multiple streams on the same column.
+</p>
+</blockquote>
+
+
+<hr/>
+<blockquote>
+<h3>
+<a name="781"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-781">DERBY-781</a>
+</h3>
+<h4>Problem</h4>
+<p>
+When optimizing a query that has one or more non-flattenable subqueries in the FROM clause, Derby will now check to see if it is possible to perform a hash join with that subquery as the inner table. Prior to Derby 10.2, the optimizer would never consider a hash join with a subquery; it only did nested loop joins.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<p>
+There is no way to disable/workaround this new behavior since the symptom as described above is a good one for Derby.
+</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>
+</blockquote>
+
+
+
+<hr/>
+<blockquote>
+<h3>
+<a name="822"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-822">DERBY-822</a>
+</h3>
+<h4>Problem</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<p>
+Pre-fetching moves execution of retrieval of data earlier for network client/server configurations.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<p>
+This was an intentional behavior change to improve performance. No Derby product solution is offered.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<p>
+Application code needs to be changed to adjust error handling if
+needed.
+</p>
+</blockquote>
+
+
+
+<hr/>
+<blockquote>
+<h3>
+<a name="1130"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-1130">DERBY-1130</a>
+</h3>
+<h4>Problem</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<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".
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<p>
+The database name was constructed wrongly in the client driver.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<p>
+If using release prior to version 10.2, make sure database name is set
+only as a DataSource property when using Derby's client DataSources.
+</p>
+</blockquote>
+
+<hr/>
+<blockquote>
+<h3>
+<a name="1295"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-1295">DERBY-1295</a>
+</h3>
+<h4>Problem</h4>
+<p>
+Result sets of type TYPE_SCROLL_INSENSITIVE used to implicitly close
+when positioned at the end in autocommit mode.
+</p>
+</ul>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<p>
+Fix applications which rely on the previous, non-standard behavior.
+</p>
+</blockquote>
+
+
+<hr/>
+<blockquote>
+<h3>
+<a name="1314"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-1314">DERBY-1314</a>
+</h3>
+<h4>Problem</h4>
+<p>
+The behaviour of executeQuery() and executeUpdate() did not match the
+JDBC specification when invoking stored procedures.
+</p>
+</ul>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<p>
+The methods executeQuery() and executeUpdate() were not implemented in
+compliance with the JDBC specification.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<p>
+In Derby 10.2, the behaviour of the methods executeQuery() and
+executeUpdate() has been changed to match the JDBC specification.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<p>
+Use execute() instead of executeUpdate()/executeQuery() to invoke a
+stored procedure which does not return exactly 0 or 1 ResultSet
+objects.
+</p>
+</blockquote>
+
+
+WORKAROUND
+
+None.
+<hr/>
+<blockquote>
+<h3>
+<a name="1323"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-1323">DERBY-1323</a>
+</h3>
+<h4>Problem</h4>
+<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>
+</ul>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<p>
+Calls to any of these methods while not on a row will now throw
+SQLException with SQLState 24000.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<p>
+Derby now disallows these calls when not on a row.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<p>
+Fix applications which rely on this non-standard behavior.
+</p>
+</blockquote>
+
+
+
+<hr/>
+<blockquote>
+<h3>
+<a name="1357"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-1357">DERBY-1357</a>
+</h3>
+<h4>Problem</h4>
+<p>
+The optimizer will now abandon sub-optimal join orders as soon as it realizes that they cost more than the best join order so far.
+</p>
+
+<p>
+This fix also ensures that, in the case of short-circuited join orders, Derby will still generate (and execute) an overall plan that matches the "best path" decisions made by the optimizer--which was not always the case prior to these changes.
+</p>
+</ul>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<p>
+There is no way to disable/workaround this new behavior since the symptom as described above is a good one for Derby.
+</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 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>
+</blockquote>
+
+<hr/>
+<blockquote>
+<h3>
+<a name="1384"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-1384">DERBY-1384</a>
+</h3>
+<h4>Problem</h4>
+<p>
+Default BLOB/CLOB length should be the maximum length supported by Derby (2G-1)
+</p>
+</ul>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<p>
+An application that used BLOB will current reject values greater than 1M, changing the default means the application will now silently accept those values.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<p>
+The allowable size of Derby LOBs has been increased.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<p>
+This was an intentional change to make Derby conform to its own
+documentation.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<p>
+Fix applications which rely on Derby rejecting LOBs that are bigger
+than 1M.
+</p>
+</blockquote>
+
+
+
+<hr/>
+<blockquote>
+<h3>
+<a name="1621"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-1621">DERBY-1621</a>
+</h3>
+<h4>Problem</h4>
+<p>
+Trigger action statement is not recompile when there is a change that would affect it.
+</p>
+</ul>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<p>
+(1) Trigger action such as an INSERT statement does not get recompiled when the underlying
+table is affected by a CREATE or DROP INDEX statement. e.g.:
+</p>
+
+<blockquote><pre>
+ create table t (i int);
+ create table t2 (i int);
+ create trigger tt after insert on t for each statement mode db2sql insert into t2 values 1;
+ insert into t values 1;
+ select * from t2;
+ create unique index tu on t2(i);
+ insert into t values 1;
+ select * from t2;
+ insert into t values 1;
+ 1 row inserted/updated/deleted
+</pre></blockquote>
+
+<p>
+The above example creates an unique index on table t2. when the trigger is fired, it did not
+raise an unique constraint error.
+</p>
+
+<p>
+(2) When the trigger action statement underlying view gets dropped, the trigger statement did not get
+recompiled. e.g.:
+</p>
+
+<blockquote><pre>
+ create table t11 (c111 int not null primary key, c112 int);
+ insert into t11 values(1,1);
+ insert into t11 values(2,2);
+ create view v21 as select * from user1.t11;
+ create table t31 (c311 int);
+ create table t32 (c321 int);
+ create trigger tr31t31 after insert on t31 for each statement mode db2sql insert into t32 values (select c111 from user1.v21 where c112=1);
+ insert into t31 values(1);
+ select * from t31;
+ select * from t32;
+ drop view v21;
+ insert into t31 values(1);
+</pre></blockquote>
+
+<p>
+In the above example, a view which the trigger action references is dropped; however, the last SQL
+INSERT statement did not throw an error.
+</p>
+
+<p>
+(3) Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger.
+The trigger action is not being recompiled and raises SQLSTATE XSAI2 even though the table being
+dropped was recreated again. e.g.:
+</p>
+
+<blockquote><pre>
+ create table t1 (id int, name varchar(20));
+ create table t2 (id int);
+ create trigger test_trigger after insert on t2 for each row mode db2sql insert into t1 values(100, 'hundred');
+ insert into t2 values(1);
+ insert into t2 values(1);
+ select * from t1;
+ drop table t1;
+ insert into t2 values(1);
+ create table t1 (id int, name varchar(20));
+ insert into t2 values(1);
+</pre></blockquote>
+
+<p>
+In the above example, a table which the trigger action references is dropped. The last INSERT
+statement should execute successfully but it raises SQLSTATE XSAI2: The conglomerate (896)
+requested does not exist.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<p>
+Derby did not perform invalidation of the trigger action when object(s) that the trigger
+references are modified or dropped; hence, resulting in the stated problem above. The
+affected versions are Derby 10.0 and 10.1.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<p>
+A fix to resolve the above Derby symptoms is available in 10.2.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<p>
+None.
+</p>
+</blockquote>
+
+
+<hr/>
+<blockquote>
+<h3>
+<a name="1652"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-1652">DERBY-1652</a>
+</h3>
+<h4>Problem</h4>
+<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>
+</ul>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<p>
+(1) When defining a trigger for the first time for a table, e.g.:
+</p>
+
+<blockquote><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></blockquote>
+
+
+<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>
+
+<blockquote><pre>
+ UPDATE TEST SET INFO = 1 WHERE TESTID = 2;
+ ERROR 54038: Maximum depth of nested triggers was exceeded.
+</pre></blockquote>
+
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<p>
+Derby's 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>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<p>
+A fix to resolve the above Derby symptom is available in 10.1 and 10.2.
+thrown now.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<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>
+
+<blockquote><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></blockquote>
+
+<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>
+</blockquote>
+
+
+<hr/>
+<blockquote>
+<h3>
+<a name="1867"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-1867">DERBY-1867</a>
+</h3>
+<h4>Problem</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Cause</h4>
+<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>
+</blockquote>
+
+<blockquote>
+<h4>Solution</h4>
+<p>
+You must use another JCE provider.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Workaround</h4>
+<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>
+</blockquote>
+
<h2><a name="Build Environment"></a>Build Environment</h2>