db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From siddharth srivastava <akssps...@gmail.com>
Subject GSoC 2011 Proposal: Derby Test and Fix
Date Mon, 28 Mar 2011 13:27:51 GMT

Following is my proposal for GSoC 2011 for the project Derby Test and Fix: I
request the community to pease provide your feedback and suggestions for it.


The proposal has been categorized in six phases as follows:
*1)Derby-5014: Tests should restore the timeout values to default after they
are done running.*

The tests to be fixed in this issue:
1) ErrorMessageTest.java 2) StressMultiTest.java 3) Sttest.java 4)
SysinfoTest.java 5)DatabaseMetaDataTest.java 6)

In these tests, the timout values (deadlock timeout, wait timout) are being
changed when they start running , but they are not restored to appropriate
values once the test finishes running.

The issue primarily requires changing the callable statements to set the
properties with the help of DatabasePropertyTestSetup decorator. The lock
timeouts in the above tests can be adjusted with the help of the function
“setLockTimeouts (Test test, int deadlockTime, int waitTime)” in the class
DatabasePropertyTestSetup. The class DatabasePropertyTestSetup, ensures that
the old values of the properties, if changed before execution, are restored
after the execution is over.

*2)Derby-4795: Starting network server with -ssl turns SSL off*

If no mode is specified while starting the network server with –ssl option
for example with “java -jar derbynet.jar start –ssl”, the SSL is turned off.
Turning off ssl with an empty sslmode argument is unintuitive and is
susceptible to errors.

A better approach, in the absence of sslmode argument would be to output an
error and display the usage guidelines for sslmode such as:

Error<error-code> : Missing <sslmode> argument

Usage: -ssl <sslmode>

SSLMODE can be any of the following:
SSL_OFF: Turns off SSL. No SSL encryption would be used
SSL_BASIC: Use basic SSL Encryption
SSL_PEER_AUTHENTICATION: Use SSL Encryption with Peer Authentication

*3) Derby-4779: NPE while inserting into a table which has a generated
column and an insert trigger*

The problem in this issue seems to be due to an invalid result set. The
error originates from EmbedStatement.java where statement is executed. The
inability to process the resultset becomes more clear with the error at
GenericPreparedStatement.java:436 i.e. resultSet.open().
This propagates to the function getNextRowCore() in InsertResultSet.java
which expects the source resultset to return the next row of the result set,
which is required by the trigger to insert the rows in the table “dummy” as
per the repro attached with this issue. As the row has not been obtained
from the result set, it causes a NullPointerException to occur and in
consequence closes the connection.

*4)Derby-4249: Create a simple store recovery test in JUnit*

Derby tests are categorized into two categories: harness test and JUnit
test. The JUnit tests have the advantage that they can be run using JUnit’s
TestRunner without explicitly needing any command line setup, the Test Suite
class makes it easier to write and standardize the writing of JUnit test
cases, hence is the need of converting the harness test cases to JUnit test

The aim is to provide a basic framework which can be established as a model
for conversion of harness store recovery tests to JUnit.
The test would do the following:
(a) Connect, create a table, commit and shutdown the database.
(b) fork a jvm, add one row, commit, add another row, exit the jvm.
(c) Reconnect with the first jvm and verify that the first row is there and
the second is not.

This cycle would ensure that the database can recover from uncommitted
changes as well as that the committed changes become persistent.

5)DERBY-3676 : Make the toString() method of Derby PreparedStatements print
out SQL text with ? parameters replaced by the values that have been set so

This issue already has a lot of discussion and patches behind it. The
approach behind this phase would be to:
a)Study the existing patches and discuss with the community the possible
reasons due to which the patches were not committed.
b)Identify a way to execute a query against the virtual table with new
string representation. Also look into the possibility of modifications to
the statement cache virtual table implementation so as to maintain the
backward compatibility.

*6)Converting Recovery tests to JUnit (this doesn’t have a Jira issue as of

This issue would act as a follow up of Derby-4249 to convert existing
harness recovery tests to JUnit test using the model proposed in phase-4.
I plan to convert the following recovery tests to JUnit:

These recovery tests run in coordination. The test oc_rec1 creates a table,
inserts and then deletes rows from it and commit it which is followed by a
series of insertion of rows in the existing table in oc_rec2, oc_rec3 and
oc_rec4. The tests oc_rec2 and oc_3 also create table and insert, delete,
compress rows in it and leave the table thus produced in committed or
uncommitted state which is tested by the next corresponding test (oc_rec3
for oc_rec2, oc_rec4 for oc_rec3) for recovery.
The aim of this issue is to transform this behavior in JUnit using the
recovery model proposed in phase 4 of this proposal.


Note: The proposal with detailed timeline is posted at my blog[1]

1) Derby 5014: Tests should restore the timeout values to default after they
are done running.
         Timeline: May 22- 5th June 2011 (15 days)

2) Derby-4795: Starting network server with -ssl turns SSL off
        Timeline: 6th June - 13th June 2011 ( 8 days)

3) Derby- 4779: NPE while inserting into a table which has a generated
column and an insert trigger
       Timeline: : 14th June-26th June 2011 (15 days)


4) Derby-4249:Create a simple store recovery test in JUnit
       Timeline: 30th June- 19th July (20 days)

5) DERBY-3676 : Make the toString() method of Derby PreparedStatements print
out SQL text with ? parameters replaced by the values that have been set so
      Timeline: 20th July- 2nd August (14 days)

6) Store Recovery test conversion
     Timeline: 3rd August -  15th August (  14 days)

[1] I have also made it available on this blog so that updating it becomes


Siddharth Srivastava

View raw message