A connection request that has a default schema that is being created by another transaction will fail to connect

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.

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 ...

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.