Kristian Waagan wrote:
[EMAIL PROTECTED] 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
