db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre Tjeldvoll <Dyre.Tjeldv...@Sun.COM>
Subject Re: 10.4 Feature Freeze
Date Tue, 26 Feb 2008 19:05:13 GMT
Kristian Waagan wrote:
> Dyre.Tjeldvoll@Sun.COM wrote:
>> ... is fast approaching (2008-02-29)
>>
>> Is this still a reasonable date, or should we consider delaying it?
>>
> 
> [snip - other work going on]
> 
>> Client stm cache         On track
> 
> I'm still working hard to get this done.
> In my last run of suites.All with connections obtained from CPDS (I'm 
> only able to easily force this for the tests calling defaultSuite / 
> clientServerDecorator), I had 14 failures and 4 errors. When I ran with 
> CPDS but statement pooling disabled, I got 13 failures, which I believe 
> indicates that there are existing bugs in the logical connection 
> implementation in the client driver.
> See DERBY-3440 for some more details.
> 
> Note that with the TestConfiguration hack, around 3100 connections out 
> of a total of around 9500 are obtained through CPDS, so the coverage is 
> far from complete, and I don't believe I can expect that either.
> 
> Known remaining work:
> (DERBY-3440 : Run suites.All with statement pooling enabled and classify 
> the problems occurring)
> DERBY-3441 : Determine and implement a proper procedure for resetting a 
> prepared statement for reuse in a statement pool
>  - awaiting review
> DERBY-3329 : Enable statement pooling in the client JDBC driver
>  - trivial, have patch already
> DERBY-3457 : Closing a logical connection must close all associated 
> logical statements
>  - awaiting review
> DERBY-3446 : Commit the test.
> DERBY-3326 : Fix bug regarding prepareStatement(String,String[]|int[])
>  - awaiting review
> DERBY-3326 : Integrate DERBY-3192 (assumed to be trivial)
> 
> In addition, there are the JIRAs for existing bugs in the client driver 
> affecting statement pooling (or more specifically connection pooling).
> See comment in DERBY-3440 for a list. It might not be exhaustive.
> 
> As an additional testing step I hope to run a J2EE test with statement 
> pooling enabled, to see if any new problems show up.

Thank you for a great summary. While there is some work left, this 
doesn't strike me as problematic. It seems like the feature will be 
largely complete in time for feature freeze. I certainly don't expect 
you to fix all existing bugs in the connection pool implementation 
before feature freeze just because your testing has uncovered them...

> Finally, if you feel I'm moving too fast and committing patches too 
> quickly, let me know. Or better yet, review the patches and give me 
> feedback :)
> I'm trying to let the patches sit in JIRA for a short while, but taken 
> the short time until feature freeze, I don't have the time to wait for 
> days for each patch. 

I don't see this as a problem. It is still possible to review patches 
post commit and you have been very vocal on the list about what you do.

> I feel I can take this liberty because I'm mostly 
> working on new code and my changes don't disturb the work of other 
> contributers. And, the changes won't affect users unless they choose to 
> use the feature, and the feature can be disabled by modifying a single 
> class.

+1

But if you prefer to have more time you could join the replication guys 
and argue for a one week extension.


Dyre

Mime
View raw message