You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Dy...@Sun.COM on 2008/02/26 11:39:59 UTC
10.4 Feature Freeze
... is fast approaching (2008-02-29)
Is this still a reasonable date, or should we consider delaying it?
Here is the current status (based on what I know):
Feature Status
--------------------------------------------------
SQL roles Delayed (disabled)
System privileges On track
SQL OLAP (row-number) On track
Unique constraints On track
Replication On track
VTI Completed
JMX On track
SQL bracketed comments Completed
IJ continuation marker Completed
Client stm cache On track
Session data caching On track
Buffer manager On track
More info can be found at
http://wiki.apache.org/db-derby/DerbyTenFourRelease
Thanks,
--
Dyre Tjeldvoll
Re: 10.4 Feature Freeze
Posted by Dy...@Sun.COM.
Bryan Pendleton <bp...@amberpoint.com> writes:
> Dyre.Tjeldvoll@Sun.COM wrote:
>> Here is the current status (based on what I know):
>
> Hi Dyre, thanks for all the great work on the 10.4 release!
>
> I think we should remove the OLAP item from the list, as
> we haven't made much progress on it and there won't be
> much done for OLAP in the 10.4 release. It's possible that we'll get
> DERBY-2998 done, so maybe replace the general OLAP item
> with just the DERBY-2998 target?
Ok, sounds reasonable.
>
> I tried to edit the wiki myself but got some sort of
> internal "wiki is down" error. Are you getting similar errors?
No, but it has been a while since I edited anything. I'll try it and see
what happens.
--
dt
Re: 10.4 Feature Freeze
Posted by Kristian Waagan <Kr...@Sun.COM>.
Bryan Pendleton wrote:
> Dyre.Tjeldvoll@Sun.COM wrote:
>> Here is the current status (based on what I know):
>
> Hi Dyre, thanks for all the great work on the 10.4 release!
>
> I think we should remove the OLAP item from the list, as
> we haven't made much progress on it and there won't be
> much done for OLAP in the 10.4 release. It's possible that we'll get
> DERBY-2998 done, so maybe replace the general OLAP item
> with just the DERBY-2998 target?
>
> I tried to edit the wiki myself but got some sort of
> internal "wiki is down" error. Are you getting similar errors?
I'm not, but maybe the error has been fixed already.
--
Kristian
>
> thanks,
>
> bryan
>
Re: 10.4 Feature Freeze
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Dyre.Tjeldvoll@Sun.COM wrote:
> Here is the current status (based on what I know):
Hi Dyre, thanks for all the great work on the 10.4 release!
I think we should remove the OLAP item from the list, as
we haven't made much progress on it and there won't be
much done for OLAP in the 10.4 release. It's possible that we'll get
DERBY-2998 done, so maybe replace the general OLAP item
with just the DERBY-2998 target?
I tried to edit the wiki myself but got some sort of
internal "wiki is down" error. Are you getting similar errors?
thanks,
bryan
Re: 10.4 Feature Freeze
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Dyre.Tjeldvoll@Sun.COM wrote:
>
>> Here is the current status (based on what I know):
>>
>> Feature Status
>> --------------------------------------------------
>
>> System privileges On track
> Have you any more information on the state of this? Martin said he
> was working on a new patch on 02/13 but nothing since then. I asked
> yesterday if a new patch was coming up but no reply yet.
>
>> VTI Completed
> Has a potential data corrupting bug associated with it DERBY-3341
I will take a look at this one.
Regards,
-Rick
>
> Dan.
Re: 10.4 Feature Freeze
Posted by Daniel John Debrunner <dj...@apache.org>.
Martin Zaun wrote:
>
> Dyre.Tjeldvoll@Sun.COM wrote:
>> Daniel John Debrunner <dj...@apache.org> writes:
>>
>>> Dyre.Tjeldvoll@Sun.COM wrote:
>>>
>>>> Here is the current status (based on what I know):
>>>>
>>>> Feature Status
>>>> --------------------------------------------------
>>>> System privileges On track
>>> Have you any more information on the state of this?
>
> a) The latest patch, just published, addresses the J2ME/CDC failures;
> I hope this blocking issues is resolved, but we probably want to
> wait for some confirming J2ME/CDC test results. I'm not aware of
> other, major objections, and it was suggested to handle follow-up
> and polishing items in a separate JIRA.
The format of SystemPrincipal identifiers in policy files (and as the
argument SystemPrincipal's constructor) does not match what a technical
discussion in DERBY-2109 decided, see DERBY-3477. This is due an
unforeseen limitation in the way the Java security implementation
handles Principal names in policy files. The resulting format
implemented by the patch does not really make sense (not the
implementor's fault, it's due to the limitation) and will be hard to
explain to users (connection requests that lead to identical database
identifiers end up with different permissions). An implementation cannot
be driving a format that is security critical and part of the Derby's
public api. In addition in trying to work around the format limitations
a security hole has been introduced (I'll add details to DERBY-3477).
Then the addition of JMX using system permissions has led to the
realization that the names don't match the expected format for
permissions in terms of "name" (object the permission applies to) and
"actions" (actions on that object). This can often happen when a single
use of an object is expanded.
So while I think there are no major objections to the current patch (I
haven't looked at v12 yet), I don't think the remaining items should be
seen as just polishing, and thus they may take some amount of effort
including some design. I see the current patch as a great step forward,
but somewhat flawed, but provides a framework to proceed.
Thus while the work done specifically in DERBY-2109 may be near to
completion, its sub-tasks and related issues may not be and I think
those need to be completed before a release. Mainly because they are
both defining public api's and are security related, both things that we
as a community should try to get right thus not having to deal with
changing formats and backwards compatibility later.
Dan.
Re: 10.4 Feature Freeze
Posted by Martin Zaun <Ma...@Sun.COM>.
Dyre.Tjeldvoll@Sun.COM wrote:
> Daniel John Debrunner <dj...@apache.org> writes:
>
>> Dyre.Tjeldvoll@Sun.COM wrote:
>>
>>> Here is the current status (based on what I know):
>>>
>>> Feature Status
>>> --------------------------------------------------
>>> System privileges On track
>> Have you any more information on the state of this?
a) The latest patch, just published, addresses the J2ME/CDC failures;
I hope this blocking issues is resolved, but we probably want to
wait for some confirming J2ME/CDC test results. I'm not aware of
other, major objections, and it was suggested to handle follow-up
and polishing items in a separate JIRA.
b) Due to some functional changes applied over the last weeks (e.g.
checks for authorization regardless of prior authentication) and
some limitations that can't be worked around (e.g. regarding
Authorization Ids in policy files), I've planned to restate the
exact compatibility issues of System Privileges for derby-dev.
This discussion about further options (to be handled in a separate
JIRA, I think) and documentable restrictions might take 1-2 weeks.
c) There's a documentation task for System Privileges (derby guides),
which can partly overlap with b) and also might take 1-2 calendar
weeks (need to get to know the documentation-related tools).
d) Finally, I have some tests that need some more work before they
can be included in the test suites.
While I'm cautiously optimistic about a) and hope that d) can be
checked in later, I'm not sure what people think about b) and c)
being a requirement for feature freeze.
Martin
Re: 10.4 Feature Freeze
Posted by Dy...@Sun.COM.
Daniel John Debrunner <dj...@apache.org> writes:
> Dyre.Tjeldvoll@Sun.COM wrote:
>
>> Here is the current status (based on what I know):
>>
>> Feature Status
>> --------------------------------------------------
>
>> System privileges On track
> Have you any more information on the state of this?
Nope. I just assumed that since there had been no "won't be done"
warning, is was still targeted for 10.4.
> Martin said he was working on a new patch on 02/13 but nothing since
> then. I asked yesterday if a new patch was coming up but no reply yet.
I see. I have not followed that discussion closely, and was under the
impression that the remaining issues were minor ones.
>
>> VTI Completed
> Has a potential data corrupting bug associated with it DERBY-3341
I did not know that. I'll take a look.
--
dt
Re: 10.4 Feature Freeze
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Dyre.Tjeldvoll@Sun.COM wrote:
>
>> Here is the current status (based on what I know):
>>
>> Feature Status
>> --------------------------------------------------
>
>> System privileges On track
> Have you any more information on the state of this? Martin said he
> was working on a new patch on 02/13 but nothing since then. I asked
> yesterday if a new patch was coming up but no reply yet.
I think that Martin is close to posting a patch for this. He hasn't
responded yet but I suspect he is polishing some corner case. I would
give him time to respond.
>
>> VTI Completed
> Has a potential data corrupting bug associated with it DERBY-3341
>
> Dan.
Re: 10.4 Feature Freeze
Posted by Daniel John Debrunner <dj...@apache.org>.
Dyre.Tjeldvoll@Sun.COM wrote:
> Here is the current status (based on what I know):
>
> Feature Status
> --------------------------------------------------
> System privileges On track
Have you any more information on the state of this? Martin said he
was working on a new patch on 02/13 but nothing since then. I asked
yesterday if a new patch was coming up but no reply yet.
> VTI Completed
Has a potential data corrupting bug associated with it DERBY-3341
Dan.
Re: 10.4 Feature Freeze
Posted by Dyre Tjeldvoll <Dy...@Sun.COM>.
Anurag Shekhar wrote:
> Dyre.Tjeldvoll@Sun.COM wrote:
>> ... is fast approaching (2008-02-29)
>>
>> Is this still a reasonable date, or should we consider delaying it?
>>
>>
>>
>> Unique constraints On track
>>
> I have all the patches (3 of them) in jira and there are chances that
> they might get commited before 29th but having one more week in hand
> will be lot more comfortable.
Ok, noted.
> Also I would like write a couple of multi threaded tests to test locking
> behavior of unique constraint.
Sounds like a good idea, :)
Dyre
Re: 10.4 Feature Freeze
Posted by Anurag Shekhar <An...@Sun.COM>.
Dyre.Tjeldvoll@Sun.COM wrote:
> ... is fast approaching (2008-02-29)
>
> Is this still a reasonable date, or should we consider delaying it?
>
>
>
> Unique constraints On track
>
I have all the patches (3 of them) in jira and there are chances that
they might get commited before 29th but having one more week in hand
will be lot more comfortable.
Also I would like write a couple of multi threaded tests to test locking
behavior of unique constraint.
anurag
Re: 10.4 Feature Freeze
Posted by Dy...@Sun.COM.
Jørgen Løland <Jo...@Sun.COM> writes:
> Dyre.Tjeldvoll@Sun.COM wrote:
>> Replication On track
>
> The 10.4 replication functionality is done, but I would be a lot more
> confident in this new functionality if we had the time to add a lot of
> tests. I would prefer that we move code-freeze to end of next week to
> add tests, but I'll leave that decision to you.
I don't have a problem with this myself, but I would like to know what
the community thinks before making a decision.
--
dt
Re: 10.4 Feature Freeze
Posted by Jørgen Løland <Jo...@Sun.COM>.
Dyre.Tjeldvoll@Sun.COM wrote:
> Replication On track
The 10.4 replication functionality is done, but I would be a lot more
confident in this new functionality if we had the time to add a lot of
tests. I would prefer that we move code-freeze to end of next week to
add tests, but I'll leave that decision to you.
--
Jørgen Løland
Re: 10.4 Feature Freeze
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Dyre.Tjeldvoll@Sun.COM writes:
> SQL roles Delayed (disabled)
To clarify, not disabled on trunk, but will be on the 10.4 branch,
tracked by DERBY-3460.
Dag
Re: 10.4 Feature Freeze
Posted by Thomas Nielsen <Th...@Sun.COM>.
Dyre.Tjeldvoll@Sun.COM wrote:
> SQL OLAP (row-number) On track
I hope to be able to wrap up the ROW_NUMBER() work over the next couple
of days - but no guarantee as of now.
Thomas
--
Thomas Nielsen
Re: 10.4 Feature Freeze
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>> Daniel John Debrunner wrote:
>
>>> I'm trying to add Java security manager checks (DERBY-3462) to the
>>> JMX MBeans so that security is not compromised by the addition of
>>> JMX. While I'm not blocked by DERBY-2109, if I proceed ahead of
>>> DERBY-2019 committing code JMX related permission code then any
>>> DERBY-2109 patch will have to re-worked again. However since there
>>> doesn't seem to be any activity on DERBY-2109 I may just go ahead
>>> anyway.
>>>
>>> Dan.
>> Please do not do this, at least not in a way which will make it
>> necessary to rework and retest DERBY-2109.
>
> I'll avoid doing this, I think there is a temp workaround I can do. If
> we get to the branch cutoff though without any progress on DERBY-2109
> then changes may need to be made.
Thanks, Dan.
>
>> Martin is actively working on this feature and deserves our patience
>> and respect.
>
> That's great, but you have to look at it from the issue of activity on
> the list: Given no messages for over two weeks from any contributor
> there are a number of scenarios one can imagine from not being active
> on derby anymore to being stuck on a problem that the community could
> possibly help with. Without communication it's impossible to tell so
> one has to assume not active if one wants to fry a fish in the same or
> overlapping area.
>
>> Each rework/retest cycle is turning out to be very expensive.
>
> Is there a way the community could help, posting a newer version of
> the patch, helping solve issues, running the tests on various platforms?
It looks as though Martin has posted a comment on DERBY-2109.
>
> I think this patch would have benefited from continuing the
> incremental development approach it started with. The current patch is
> trying to solve at least four issues. With an incremental approach my
> opinion is that most of the current patch's functionality could have
> already been committed, allowing focus on specific problems and a
> quicker turn-around on testing etc. I wonder if some folks are
> reluctant to perform incremental development because they think
> patches are too slow to be applied, thus they do a mega-patch which of
> course will take time to commit, thus we have a self-fulfilling prophecy?
>
> Dan.
Re: 10.4 Feature Freeze
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> I'm trying to add Java security manager checks (DERBY-3462) to the JMX
>> MBeans so that security is not compromised by the addition of JMX.
>> While I'm not blocked by DERBY-2109, if I proceed ahead of DERBY-2019
>> committing code JMX related permission code then any DERBY-2109 patch
>> will have to re-worked again. However since there doesn't seem to be
>> any activity on DERBY-2109 I may just go ahead anyway.
>>
>> Dan.
> Please do not do this, at least not in a way which will make it
> necessary to rework and retest DERBY-2109.
I'll avoid doing this, I think there is a temp workaround I can do. If
we get to the branch cutoff though without any progress on DERBY-2109
then changes may need to be made.
> Martin is actively working on
> this feature and deserves our patience and respect.
That's great, but you have to look at it from the issue of activity on
the list: Given no messages for over two weeks from any contributor
there are a number of scenarios one can imagine from not being active on
derby anymore to being stuck on a problem that the community could
possibly help with. Without communication it's impossible to tell so one
has to assume not active if one wants to fry a fish in the same or
overlapping area.
> Each rework/retest cycle is turning out to be very expensive.
Is there a way the community could help, posting a newer version of the
patch, helping solve issues, running the tests on various platforms?
I think this patch would have benefited from continuing the incremental
development approach it started with. The current patch is trying to
solve at least four issues. With an incremental approach my opinion is
that most of the current patch's functionality could have already been
committed, allowing focus on specific problems and a quicker turn-around
on testing etc. I wonder if some folks are reluctant to perform
incremental development because they think patches are too slow to be
applied, thus they do a mega-patch which of course will take time to
commit, thus we have a self-fulfilling prophecy?
Dan.
Re: 10.4 Feature Freeze
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Dyre.Tjeldvoll@Sun.COM wrote:
>> John Embretsen <Jo...@Sun.COM> writes:
>>
>>> Dyre.Tjeldvoll@Sun.COM wrote:
>>>> ... is fast approaching (2008-02-29)
>>>>
>>>> Is this still a reasonable date, or should we consider delaying it?
>>>>
>>>>
>>>> Here is the current status (based on what I know):
>>>> JMX On track
>>> JMX is on track per se, as it has not been defined what exactly will
>>> be part of
>>> 10.4. However, this is still work in progress, but I guess it is up
>>> to you as
>>> release manager to decide what to let into the release or not.
>>
>> It is, but some JMX stuff has already been committed, hasn't it. And
>> since what Derby offers through JMX isn't regulated by a standard, I
>> would think that you have quite a bit of leeway in terms of defining
>> when the feature is complete... :)
>
> I'm trying to add Java security manager checks (DERBY-3462) to the JMX
> MBeans so that security is not compromised by the addition of JMX.
> While I'm not blocked by DERBY-2109, if I proceed ahead of DERBY-2019
> committing code JMX related permission code then any DERBY-2109 patch
> will have to re-worked again. However since there doesn't seem to be
> any activity on DERBY-2109 I may just go ahead anyway.
>
> Dan.
Please do not do this, at least not in a way which will make it
necessary to rework and retest DERBY-2109. Martin is actively working on
this feature and deserves our patience and respect. Each rework/retest
cycle is turning out to be very expensive.
-Rick
Re: 10.4 Feature Freeze
Posted by Daniel John Debrunner <dj...@apache.org>.
Dyre.Tjeldvoll@Sun.COM wrote:
> John Embretsen <Jo...@Sun.COM> writes:
>
>> Dyre.Tjeldvoll@Sun.COM wrote:
>>> ... is fast approaching (2008-02-29)
>>>
>>> Is this still a reasonable date, or should we consider delaying it?
>>>
>>>
>>> Here is the current status (based on what I know):
>>> JMX On track
>> JMX is on track per se, as it has not been defined what exactly will be part of
>> 10.4. However, this is still work in progress, but I guess it is up to you as
>> release manager to decide what to let into the release or not.
>
> It is, but some JMX stuff has already been committed, hasn't it. And
> since what Derby offers through JMX isn't regulated by a standard, I
> would think that you have quite a bit of leeway in terms of defining
> when the feature is complete... :)
I'm trying to add Java security manager checks (DERBY-3462) to the JMX
MBeans so that security is not compromised by the addition of JMX. While
I'm not blocked by DERBY-2109, if I proceed ahead of DERBY-2019
committing code JMX related permission code then any DERBY-2109 patch
will have to re-worked again. However since there doesn't seem to be any
activity on DERBY-2109 I may just go ahead anyway.
Dan.
Re: 10.4 Feature Freeze
Posted by Dy...@Sun.COM.
John Embretsen <Jo...@Sun.COM> writes:
> Dyre.Tjeldvoll@Sun.COM wrote:
>> ... is fast approaching (2008-02-29)
>>
>> Is this still a reasonable date, or should we consider delaying it?
>>
>>
>> Here is the current status (based on what I know):
>
>> JMX On track
>
> JMX is on track per se, as it has not been defined what exactly will be part of
> 10.4. However, this is still work in progress, but I guess it is up to you as
> release manager to decide what to let into the release or not.
It is, but some JMX stuff has already been committed, hasn't it. And
since what Derby offers through JMX isn't regulated by a standard, I
would think that you have quite a bit of leeway in terms of defining
when the feature is complete... :)
>
> I have plans to contribute some JMX tests (DERBY-3385; might submit something
> today, but then I'll be on vacation for about a week). There are also some minor
> changes that I would like to get in to 10.4 (proper Javadocs and minor MBean
> interface changes (DERBY-1387)), unless someone else takes care of it. So, I
> would appreciate some more time (one week, maybe two) to get this in.
>
> I also believe Bernt is working on improving one of the MBeans (DERBY-3435), and
> I think Dan may have some patches in the pipeline (DERBY-3429, DERBY-3462, ?),
> but I'll let them speak for themselves regarding the feature freeze date.
I would think that all of these things could be added after feature
freeze, if need be. They don't seem like things that could seriously
de-stabilize the branch...(?)
--
dt
Re: 10.4 Feature Freeze
Posted by John Embretsen <Jo...@Sun.COM>.
Dyre.Tjeldvoll@Sun.COM wrote:
> ... is fast approaching (2008-02-29)
>
> Is this still a reasonable date, or should we consider delaying it?
>
>
> Here is the current status (based on what I know):
> JMX On track
JMX is on track per se, as it has not been defined what exactly will be part of
10.4. However, this is still work in progress, but I guess it is up to you as
release manager to decide what to let into the release or not.
I have plans to contribute some JMX tests (DERBY-3385; might submit something
today, but then I'll be on vacation for about a week). There are also some minor
changes that I would like to get in to 10.4 (proper Javadocs and minor MBean
interface changes (DERBY-1387)), unless someone else takes care of it. So, I
would appreciate some more time (one week, maybe two) to get this in.
I also believe Bernt is working on improving one of the MBeans (DERBY-3435), and
I think Dan may have some patches in the pipeline (DERBY-3429, DERBY-3462, ?),
but I'll let them speak for themselves regarding the feature freeze date.
--
John
Re: 10.4 Feature Freeze
Posted by Dyre Tjeldvoll <Dy...@Sun.COM>.
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
Re: 10.4 Feature Freeze
Posted by Kristian Waagan <Kr...@Sun.COM>.
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.
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 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.
--
Kristian
> Session data caching On track
>
> Buffer manager On track
>
> More info can be found at
>
> http://wiki.apache.org/db-derby/DerbyTenFourRelease
>
>
> Thanks,
>
Re: 10.4 Feature Freeze
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Dyre Tjeldvoll <Dy...@Sun.COM> writes:
> Knut Anders Hatlen wrote:
>> Dyre.Tjeldvoll@Sun.COM writes:
>>
>>> ... is fast approaching (2008-02-29)
>>>
>>> Is this still a reasonable date, or should we consider delaying it?
>>>
>>>
>>> Here is the current status (based on what I know):
>> [...]
>>> Buffer manager On track
>>
>> Hi Dyre,
>>
>> The code for the buffer manager has been in the repository for quite
>> some time now, but it has not yet been enabled in
>> modules.properties. Øystein has reviewed the code and suggested some
>> improvements. I'll probably not have the time to make all the changes
>> Øystein suggested before the feature freeze date, but since the
>> improvements are mainly reorganizing some methods and improving the
>> comments, I think we could just as well enable it now before the
>> improvements have been made. I have just asked about it on JIRA, and
>> I'll wait until someone says go ahead before I enable it.
>>
>
> Ok, thanks for the update. Unless enabling it will make it difficult
> to address the review comments, I'd say go ahead.
Thanks, I just did. I hope it doesn't break anything...
--
Knut Anders
Re: 10.4 Feature Freeze
Posted by Dyre Tjeldvoll <Dy...@Sun.COM>.
Knut Anders Hatlen wrote:
> Dyre.Tjeldvoll@Sun.COM writes:
>
>> ... is fast approaching (2008-02-29)
>>
>> Is this still a reasonable date, or should we consider delaying it?
>>
>>
>> Here is the current status (based on what I know):
> [...]
>> Buffer manager On track
>
> Hi Dyre,
>
> The code for the buffer manager has been in the repository for quite
> some time now, but it has not yet been enabled in
> modules.properties. Øystein has reviewed the code and suggested some
> improvements. I'll probably not have the time to make all the changes
> Øystein suggested before the feature freeze date, but since the
> improvements are mainly reorganizing some methods and improving the
> comments, I think we could just as well enable it now before the
> improvements have been made. I have just asked about it on JIRA, and
> I'll wait until someone says go ahead before I enable it.
>
Ok, thanks for the update. Unless enabling it will make it difficult to
address the review comments, I'd say go ahead.
Dyre
Re: 10.4 Feature Freeze
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Dyre.Tjeldvoll@Sun.COM writes:
> ... is fast approaching (2008-02-29)
>
> Is this still a reasonable date, or should we consider delaying it?
>
>
> Here is the current status (based on what I know):
[...]
> Buffer manager On track
Hi Dyre,
The code for the buffer manager has been in the repository for quite
some time now, but it has not yet been enabled in
modules.properties. Øystein has reviewed the code and suggested some
improvements. I'll probably not have the time to make all the changes
Øystein suggested before the feature freeze date, but since the
improvements are mainly reorganizing some methods and improving the
comments, I think we could just as well enable it now before the
improvements have been made. I have just asked about it on JIRA, and
I'll wait until someone says go ahead before I enable it.
--
Knut Anders