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 |
|
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 |
|
Import/Export of Blob/Clob |
Add support for import/export of tables with clob, blob and other binary type columns |
|
JDBC methods for autogenerated keys |
Implement JDBC methods for autogenerated keys for Embedded |
|
CREATE TABLE AS <subquery> WITH NO DATA |
Create an new empty table based upon a sub query |
|
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. |
|
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) |
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 ,