Table of Contents

10.3 Post-mortem

See TenThreePostMortem for feedback on how we can continue to improve our release process.

10.3 Feature Release Summary

The first Derby 10.3 release is a feature release and contains both new features and many bug fixes.

Release Manager

Myrna van Lunteren (June 14 - July 27), Rick Hillegas (July 30 - ?)

Last day to commit changes

Thursday, June 14

Creating of 10.3 branch & generating 10.3.1.0 beta

Friday, June 15

Testing and Bug Fixing

June 18 - July 5

Release candidate 1 (10.3.1.1)

July 8

Sanity Testing and Voting (Cancelled - blocker DERBY-2923,2924,2931,2932)

July 8 - July 11

Release candidate 2 (10.3.1.2)

July 14

Sanity Testing and Voting (Cancelled - blocker DERBY-2986)

July 14 - July 19

Release candidate 3 (10.3.1.3)

July 19

Sanity Testing and Voting (Cancelled - blocker DERBY-1963)

July 19 - July 26

Release candidate 4 (10.3.1.4)

August 1

Close vote

August 8

Release

August 10

10.3 Branch Information

547740

10.3 branch created

547802

trunk bumped to 10.4

547817

10.3 bumped to 10.3.1.0 beta

548006

revision of 10.3.1.0 beta distribution

548419

10.3 bumped to 10.3.1.1 beta

554502

revision of 10.3.1.1 (RC1)

554516

10.3 bumped to 10.3.1.2

556213

revision of 10.3.1.2 (RC2)

556360

10.3 bumped to 10.3.1.3

557799

revision of 10.3.1.3 (RC3)

557836

10.3 bumped to 10.3.1.4

10.3 Testing

You should be able to find the latest 10.3 release candidate here.

10.3.1.4 release candidate 4 was created on August 1 at subversion revision 561794.

10.3.1.3 release candidate 3 was created July 19, 6 pm PDT, but was found to have a serious blocker when starting networkserver with -h <ipaddress>

10.3.1.2 release candidate 2 was created on July 14, 5 pm PDT, but it was found relevant to fix one more blocker issue with the collation feature before publishing an official release.

10.3.1.1 release candidate 1 was found to have some serious problems with soft upgrade.

10.3.1.0 testing details can be found on the following pages:

10.3 Big Features

Feature

Description

Associated JIRAs

DBA Powers

Control who can shutdown, encrypt and upgrade databases.

Master JIRA: DERBY-2264

Secure Server

Make the Network Server secure by default.

Master JIRA: DERBY-2196

Language Based Ordering

Add built in language based ordering and like processing to Derby.

Master JIRA: DERBY-1478

10.3 Small Features

Feature

Description

Associated JIRAs

Alter Table

You can now DROP or RENAME a column. Together with a number of enhancements in 10.2, this means that most dynamic schema modifications are now possible

DERBY-396, DERBY-165, DERBY-726, DERBY-1489, DERBY-1490, DERBY-1926, DERBY-1909, DERBY-1515, DERBY-2042

SSL/TLS

Implement SSL/TLS communication between client and server

DERBY-2108, DERBY-2356, DERBY-2272, DERBY-2273

Blob/Clob API

Support all JDBC API methods for Blob/Clob, both for embedded driver and client driver

DERBY-1341, DERBY-1285, DERBY-1286, DERBY-2443, DERBY-2444, DERBY-2730

Client Side Tracing

Provide a way to enable client tracing without changing the application

DERBY-1275

Import/Export of Blob/Clob

Add support for import/export of tables with clob, blob and other binary type columns

DERBY-378

JDBC methods for autogenerated keys

Implement JDBC methods for autogenerated keys for Embedded

DERBY-2631

CREATE TABLE AS <subquery> WITH NO DATA

Create an new empty table based upon a sub query

DERBY-64

XATransaction timeout

Support for XATransaction timeout

Master JIRA: DERBY-2432

10.3 Non-functional Improvements

Area

Description

Assosiciated JIRAs

Performance

Reduce CPU usage in embedded Derby. Main areas being worked on are: Lock manager and latching, reduced use of synchronized data structures, optimize use of bit sets.

DERBY-1704, DERBY-2107, DERBY-2149, DERBY-2150, DERBY-2191, DERBY-2226

Performance

Improve Derby's treatment of IN-lists to allow the optimizer to consider using indexes when appropriate.

DERBY-47, DERBY-713

Testing

Switch testing to be pure JUnit based.

DERBY-1952 & many others

Memory Usage

Avoid having to materialize entire LOBs in network client. The client will use locators when requesting operations to be performed on LOBs stored on the server side.

Master JIRA: DERBY-208

Platforms

Minimum JDK support will change to JDK 1.4.2 for J2SE & CDC/Foundation 1.1 for J2ME. (Removes support for JDK 1.3 and J2ME/CDC/Foundation 1.0)

DERBY-1982

10.3 Bug Fixing

The following issues block 10.3: Open 10.3 Blockers

The following bug fixes are targetted for 10.3: Open 10.3 issues

The following issues appear as regressions introduced by 10.3 (some were introduced by earlier releases): Open 10.3 Regressions

The following are open regression test bugs affecting 10.3: Open 10.3 regression issues

See HighValueFixCandidates for a list of low hanging fruit and high value fix opportunities.

See TenThreeBugPoints for information on who is reporting and fixing bugs for 10.3

10.3 Documentation Issues and Reviews

The following documentation fixes are targetted for 10.3:

Open 10.3 documentation issues

Incompatibilities Upgrading from Previous Releases

The Secure Server work (DERBY-2196) introduces the following incompatibility during upgrade from an older Derby release:

Scenario

Old behavior

New behavior

Customer needs to make these changes...

Unsecure

In this scenario, NetworkServerControl is the main entry point for the VM and the VM starts up without a SecurityManager.

The server comes up as before. However, under the hood, NetworkServerControl installs a SecurityManager. This may affect the running of customer-written procedures and functions. Application code within routines will no longer be able to perform operations that require security checks like file i/o, system-property-reading, classloading, etc..

The customer does not need to do anything if her routines are not perfoming such operations. If her routines are performing such operations then there are (at least) two choices. 1) Bring the server up with the noSecurityManager flag if the SecurityManager causes her problems-for instance, if she does not want to add privileged blocks to her procedures and functions. 2) Bring the server up with her own security manager and policy file.

The DBA Powers work (DERBY-2264) introduces the following incompatibility during upgrade from an older Derby release:

Privilege

Previous behavior...

Behavior after these changes when authentication is enabled...

Impacts...

How to upgrade application...

shutdown database

Anyone who could connect could shutdown a database.

A database can be shutdown only by its owner.

All applications which run with database or system authentication.

Anyone who must shutdown the database must connect as the Database Owner. Risk that the database owner is not a valid user in the authentication scheme, typically APP

upgrade database

Anyone who could connect could upgrade the database.

Only the Database Owner can upgrade the database.

All applications which run with database or system authentication.

Anyone who must upgrade the database must connect as the Database Owner. Risk that the database owner is not a valid user in the authentication scheme, typically APP

encrypt existing database

Anyone who could connect could encrypt an existing database (this was a new feaute added in 10.2)

Only the Database Owner can encrypt or re-encrypt the database.

All applications which run with database or system authentication.

Anyone who must encrypt the database must connect as the Database Owner. Risk that the database owner is not a valid user in the authentication scheme, typically APP

Risk of DBO being a non-authenticated user after upgrade to 10.3.

Old Release

Risk of invalid DBO

10.0, 10.1

After upgrade the DBO will be the user performing the upgrade which means the DBO will either be an authenticated user or authentication is not enabled. No risk of the the DBO not being a valid user.

10.2 without authentication

No authentication so no risk of the the DBO not being a valid user.

10.2 with authentication

The DBO will be the user who created the database or upgraded it from 10.0 or 10.1. Risk exists if authentication was changed since the database was created or updated from 10.0/10.1. Risk is probably less likely if the application is using SQL authorization as the DBO plays a critical role in that setup.

Any change to authentication in a 10.3 database must ensure that the DBO remains a valid user. With SQL authorization enabled this is more likely because typically the DBO is the only user who can change authentication (through system procedures). Though the DBO could accidently set up authentication that excluded herself.

Other changes that may affect existing applications

Thank You 10.3 Volunteers!

Please add your name if you helped with the release but are not listed here.

A B , Aaron Tarter , Anders Morken , Andreas Korneliussen , Andrew McIntyre , Anurag Shekhar , Bernt M. Johnsen , Bryan Pendleton , Dag H. Wanvik , Daniel John Debrunner , Deepa Remesh , Dyre Tjeldvoll , Fernanda Pizzorno , Francois Orsini , James F. Adams , Jean T. Anderson , Jeff Levitt , John H. Embretsen , John Peterson , Julius Stroffek , Jørgen Løland , Kathey Marsden , Kim Haase , Knut Anders Hatlen , Kristian Waagan , Laura Stewart , Mamta A. Satoor , Manish Khettry , Manjula Kutty , Mayuresh Nirhali , Mike Matrigali , Myrna van Lunteren , Olav Sandstaa , Ole Solberg , Rajesh Kartha , Ramandeep Kaur , Ramin Moazeni , Rick Hillegas , Satheesh Bandaram , Saurabh Vyas , Stan Bradbury , Sunitha Kambhampati , Suresh Thalamati , Tomohito Nakayama , Ugo Matrangolo , Unassigned , V.Narayanan , Vemund Østgaard , Yip Ng ,
Øystein Grøvlen ,

  • No labels