Apache Derby 10.4.2.0 Release

Use the links below to download a distribution of Apache Derby from one of our mirrors. 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.4.2.0-bin.zip [PGP] [MD5]
db-derby-10.4.2.0-bin.tar.gz [PGP] [MD5]

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

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

db-derby-10.4.2.0-src.zip [PGP] [MD5]
db-derby-10.4.2.0-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_plugin - provides an Apache Derby Nature in Eclipse for easy database application development.

derby_core_plugin_10.4.2.zip [PGP] [MD5]
derby_ui_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 Derby release 10.4.2.0 and the preceding release 10.4.1.3.

Overview

Derby is a pure Java relational database engine using standard SQL and JDBC as its APIs.

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 maintenance release. No new features were added.

Bug Fixes

The following issues are addressed by Derby release 10.4.2.0. These issues are not addressed in the preceding 10.4.1.3 release.

Issues

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

• Note for DERBY-3701: An error message will be logged to derby.log if the Network Server tracing file cannot be created. Starting with version 10.5, the Network Server will attempt to create the trace directory if it does not exist. Any intervening directories in the given path will also be created if possible.

• Note for DERBY-48: In Derby, a user's initial default schema is named the same as the user name, or APP if a user is not provided at connect time. This schema is implicitly auto-created the first time a schema object is created in that schema.

Note for DERBY-3701

Summary of Change

An error message will be logged to derby.log if the Network Server tracing file cannot be created. Starting with version 10.5, the Network Server will attempt to create the trace directory if it does not exist. Any intervening directories in the given path will also be created if possible.

Symptoms Seen by Applications Affected by Change

Before the fix for DERBY-3110, if derby.drda.traceAll was set to true and the derby.drda.traceDirectory was set to a non-existent directory, no tracing would occur and no error would occur. After the fix for DERBY-3110, an error "java.lang.Exception: DRDA_UnableToAccept.S:Unable to accept connections" would occur and the client would hang and no tracing would occur. With this fix for version 10.5 and higher, the Network Server will attempt to create the trace directory if possible. For 10.4.2 (and the next release on the 10.3 branch), the Network Server will still not try to create the directory. For all these releases the Network Server will print an error on session connect if there is any problem creating the trace file, but the Network Server will not cause the session connection to fail. Users who have trace turned on and the trace directory set to a non-existent directory may now see exceptions in the derby.log on connect indicating that the trace file is not found or with 10.5 or higher they may see tracing occur where it did not before.

Incompatibilities with Previous Release

Tracing properties will not be ignored or cause the client to hang if the trace directory is set to a non-existent directory.

Rationale for Change

The tracing properties should not be summarily ignored or cause the client to hang if the trace directory does not exist.

Application Changes Required

Applications that counted on the derby.drda.traceAll property being ignored if derby.drda.traceDirectory was set to a non-existent directory, need to turn tracing off or they may now see many errors in the derby.log or large amounts of tracing.

Note for DERBY-48

Summary of Change

In Derby, a user's initial default schema is named the same as the user name, or APP if a user is not provided at connect time. This schema is implicitly auto-created the first time a schema object is created in that schema.

Previously, this auto-creation would be performed as part of the user transaction. This would sometimes lead to locking issues as described in this issue. With this change, the auto-creation is now performed and committed immediately in a separate sub-transaction.

Symptoms Seen by Applications Affected by Change

The initial default schema will be present in cases where it previously would not yet have been created: If the user transaction that creates a schema object leading to auto-creation of the initial default schema rolls back for some reason after having created the schema, up till now the auto-creation of the initial default schema would be rolled back as well. Since it is now created and committed in a sub-transaction, the schema creation will not be rolled back: the default schema will persist.

Incompatibilities with Previous Release

Most applications should not be impacted by this change, but there are some corner cases as described below:

If the application tests for the existence of the initial default schema by querying Derby system tables, the results could now be different than in earlier releases, if the test is made after a rollback as described in the previous section.

Since the initial default schema will now potentially exist in cases where it would previously not exist, schema operations may be impacted, e.g. where before a DROP SCHEMA <default schema name> RESTRICT would fail due to it not yet existing, it could now work (if empty), depending on when the drop attempt is made.

Rationale for Change

Implicit schema creation is now performed in its own transaction to avoid deadlocks with other connections accessing the same schema.

Doing this is a separate transaction avoids holding dictionary locks longer than necessary, cf. DERBY-48 and thus reduces the chance for deadlocks.

Application Changes Required

Verify that the application code does not rely on the initial default schema being absent after a rollback.

Build Environment

Derby release 10.4.2.0 was built using the following environment:

• Branch - Source code came from the 10.4 branch.
• Machine - Mac OS X Version 10.5.4
• Ant - Apache Ant version 1.7.0 compiled on December 13 2006.
• JDK 1.4 - Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_16-b05-302)
• Java 6 - Java(TM) SE Runtime Environment (build 1.6.0_01-dp-b06-101)
• OSGi - The Apache Felix project supplied felix.jar, which was used to build org.apache.derby.osgi.EmbeddedActivator.
• Compiler - A Java 5 compiler was used to build all classes: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
• JSR 169 - J2ME libraries were supplied by phoneme.dev.java.net (CDC, Foundation Profile, and Personal Basis Profile meeting the 1.1.2 specifications). JSR169 libraries were supplied by java.sun.com.

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 you verify your downloads with both PGP and MD5.