Apache Derby 10.7.1.1 Release

Use the links below to download a distribution of Apache Derby. You should always verify the integrity of distribution files downloaded from a mirror.

There are four different distributions:

• bin distribution - contains the documentation, javadoc, and jar files for Derby.
• lib distribution - contains only the jar files for Derby.
• lib-debug distribution - contains jar files for Derby with source line numbers.
• src distribution - contains the Derby source tree at the point which the binaries were built.

db-derby-10.7.1.1-bin.zip [PGP] [MD5]
db-derby-10.7.1.1-bin.tar.gz [PGP] [MD5]

db-derby-10.7.1.1-lib.zip [PGP] [MD5]
db-derby-10.7.1.1-lib.tar.gz [PGP] [MD5]

db-derby-10.7.1.1-lib-debug.zip [PGP] [MD5]
db-derby-10.7.1.1-lib-debug.tar.gz [PGP] [MD5]

db-derby-10.7.1.1-src.zip [PGP] [MD5]
db-derby-10.7.1.1-src.tar.gz [PGP] [MD5] (Note that, due to long filenames, you will need gnu tar to unravel this tarball.)

There are two separate Eclipse plugins for Derby:

• derby_core_plugin - provides the Derby jar files to other plugins in Eclipse.
• derby_ui_doc_plugin - provides an Apache Derby Nature in Eclipse for easy database application development.

derby_core_plugin_10.7.1.zip [PGP] [MD5]
derby_ui_doc_plugin_1.1.2.zip [PGP] [MD5]

Please note: both plugins must be installed for full functionality. For information on installing and using the Derby plugins for Eclipse, please see the Using the 10 Core and 1.1 UI Derby plug-ins page.

These notes describe the difference between Apache Derby release 10.7.1.1 and the preceding release 10.6.2.1.

Overview

The most up to date information about Derby releases can be found on the Derby download page.

Apache Derby is a pure Java relational database engine using standard SQL and JDBC as its APIs. More information about Derby can be found on the Apache web site. Derby functionality includes:

• Embedded engine with JDBC drivers
• Network Server
• Network client JDBC drivers
• Command line tools: ij (SQL scripting), dblook (schema dump) and sysinfo (system info)

New Features

This is a feature release. The following new features were added:

• Definer's rights - Procedures and functions can now run with their creators' privileges, rather than with the current user's permissions.
• BOOLEAN data type - Boolean is now a legal data type for columns, routine arguments, and function return values.
• Table truncation - A new TRUNCATE TABLE command drops all rows in a table quickly.
• Query plan browsing - A new PlanExporter tool helps developers visualize query plans better.
• Unicode database names - Remote clients can now use database names which include Unicode characters outside the ASCII codeset.

Bug Fixes

The following issues are addressed by Derby release 10.7.1.1. These issues are not addressed in the preceding 10.6.2.1 release.

Issues

Compared with the previous release (10.6.2.1), Derby release 10.7.1.1 introduces the following new features and incompatibilities. These merit your special attention.

Note for DERBY-4786

Summary of Change

A shutdown request with no user credentials to a 10.3 (or earlier) server from a newer client will give multiple messages on both the server and client sides.

Symptoms Seen by Applications Affected by Change

A shutdown request from a 10.4 (or higher) client with no user credentials to a 10.3 (or earlier) server shows the following messages on the server side. (Note that the version info about the product changes depending on the release being used for the server.)

java.lang.Throwable: DRDA_UnknownProtocol.S, 2
Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client?
Apache Derby Network Server - 10.3.3.1 - (1) shutdown at {2}

Messages on the client side appear as follows. (Note that the version info about the product changes depending on the release being used for the client.)

Invalid reply header from network server: Invalid string . Plaintext connection attempt to an SSL enabled server?
Apache Derby Network Server - 10.7.1.0 - (1) shutdown

Rationale for Change

10.3 (and earlier) versions do not support shutdown commands with credentials. The credential-bearing shutdown command was introduced in 10.4 and requires network protocol level 2. 10.3 and earlier versions understand protocol level 1 and do not recognize the credential-bearing shutdown command. Because of this, a 10.4 (or higher) client can't shutdown a 10.3 (or lower) server. With DERBY-4786, a 10.7 client will first try the shutdown at protocol level 2. If that does not succeed, then the 10.7 client will send the shutdown at protocol level 1. This fix has been backported to the 10.4, 10.5, and 10.6 branches also. Future releases on those branches will enjoy this ability to successfully shutdown 10.3 (and earlier) servers.

Note for DERBY-4777

Summary of Change

When a network client attempts to update through an invalid cursor, Derby now throws 'ERROR 42X30' instead of 'ERROR XJ202'.

Symptoms Seen by Applications Affected by Change

In previous releases, Derby threw 'ERROR XJ202' when a network client tried to update through a closed or nonexistent cursor. For a cursor named "JDK4", the detailed message was "ERROR XJ202: Invalid cursor name 'JDK4'." If you are running 10.7, however, Derby now throws 'ERROR 42X30' instead, and the detailed message is "ERROR 42X30: Cursor 'JDK4' not found. Verify that autocommit is OFF."

From now on, DERBY performs identically in Client and Embedded modes when you attempt to update through a closed or nonexistent cursor.

Incompatibilities with Previous Release

Applications may fail if they expect 'ERROR XJ202' to be thrown in this situation.

Rationale for Change

This change was made so that the Client and Embedded behavior would be similar.

Application Changes Required

If applications need to track updates through invalid cursors, those applications should look for 'ERROR 42X30' regardless of whether they run in Client or Embedded mode.

Note for DERBY-4772

Summary of Change

Column types in the XPLAIN tables changed to accommodate more data.

Symptoms Seen by Applications Affected by Change

None.

Incompatibilities with Previous Release

None, but keeping the old table definitions for the XPLAIN tables may result in data truncation errors (see DERBY-4772 and DERBY-4673).

Rationale for Change

Amount of recorded data was too large to fit into the old column definitions.

Application Changes Required

It is recommended to drop existing XPLAIN tables and have them recreated with the new table definitions. This can be done by disabling the XPLAIN feature, dropping the tables, and then enable the XPLAIN feature again. Alternatively, if you want to keep existing data, specify a different schema to save XPLAIN data in.

Note for DERBY-4577

Summary of Change

UPDATE statements should not raise the following error: "ERROR nospc: nospc.U"

Symptoms Seen by Applications Affected by Change

An UPDATE of a row which spans multiple pages can fail, raising "ERROR nospc: nospc.U". This error should never be returned to the client. The error is very timing and data dependent, and has been encountered in only a few applications.

Rationale for Change

UPDATES of rows may fail in some cases, returning this error which clients should never see.

Application Changes Required

After applying the fix, clients should not see this error. To ensure that updates of existing rows no longer see this error, run the SYSCS_UTIL.SYSCS_COMPRESS_TABLE() system procedure on your tables. You may want to defensively compress all of your tables. Alternatively, it is also ok to wait and see if the error occurs and then only compress the tables that encounter the error.

Note for DERBY-4314

Summary of Change

Derby client Connection.setTransactionIslation will not commit if isolation level does not change.

Symptoms Seen by Applications Affected by Change

Applications relying on Connection.setTransactionIsolation to commit transactions, may see either errors related to transactions in progress or transactions that fail to commit.

Incompatibilities with Previous Release

Before 10.6.1.0, derby client Connection.setTransactionIsolation would commit even if isolation has not changed. Starting with 10.6.1.0, derby client Connection.setTransactionIsolatin does not commit if the isolation has not changed.

Rationale for Change

The change was made to client to match behavior of the embedded driver and to improve client performance.

Application Changes Required

Applications should not rely on transactions change based on calling Connection.setTransactionIsolation. An explicit commit should be called to ensure transactions commit.

Note for DERBY-1511

Summary of Change

Queries will not bulk fetch rows with large object columns if the cursor is holdable.

Symptoms Seen by Applications Affected by Change

Queries that perform full table scans in order to fetch relatively small BLOB or CLOB values, may need longer time to complete than they did in previous releases. This only affects queries that are executed on a Statement (or PreparedStatement or CallableStatement) that has the ResultSet.HOLD_CURSORS_OVER_COMMIT flag set.

Rationale for Change

The bulk fetching that happened in previous releases, was not a safe optimization if the fetched rows contained large object columns (BLOB or CLOB) and the cursor was holdable. If the transaction was committed in the middle of a scan, the pre-fetched large objects cached inside the scan would be closed, and they would not be valid for use when they were later returned to the application. To prevent certain ways to access large objects from failing, the optimization was disabled for the cases where it was not known to be safe.

Application Changes Required

The queries affected by this change will run with no performance degradation compared to previous releases if the application can be rewritten to use non-holdable cursors. This can be achieved by calling Connection.setHoldability() with the ResultSet.CLOSE_CURSORS_AT_COMMIT flag before creating the statement instance, or by supplying that flag to Connection's createStatement(), prepareStatement() or prepareCall() method in the resultSetHoldability parameter.

Alternatively, if all the BLOB and CLOB values in the table in question are small enough to fit in a VARCHAR FOR BIT DATA column or in a VARCHAR column, one may change the type of the LOB columns to one of these other data types, and the query will again be allowed to use the bulk fetch optimization.

Build Environment

Derby release 10.7.1.1 was built using the following environment:

• Branch - Source code came from the 10.7 branch.
• Machine - Mac OS X 10.5.8.
• Ant - Apache Ant version 1.7.1 compiled on June 27 2008.
• JDK 1.4 - Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_22-b02-329).
• Java 6 - Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-9M3125).
• Compiler - The 1.6.0_17-b04-248-9M3125 javac was used to compile all classes.
• JSR 169 - J2ME support was built using libraries from phoneME Advanced Milestone Release 2.

Verifying Releases

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.

The PGP signatures can be verified using PGP or GPG. First download the Apache Derby KEYS as well as the asc 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 ...

% pgpk -a KEYS
% pgpv db-derby-X.Y.tar.gz.asc

or

% pgp -ka KEYS
% pgp db-derby-X.Y.tar.gz.asc

or

% gpg --import KEYS
% gpg --verify db-derby-X.Y.tar.gz.asc

To verify the MD5 signature on the files, you need to use a program called md5 or md5sum, which is included in many unix distributions. It is also available as part of GNU Textutils. Windows users can get binary md5 programs from here, here, or here.

We strongly recommend that you verify your downloads with both PGP and MD5.