Rick Hillegas wrote:
> I think that Kathey's final goal pretty much sums up the concern which
> Suresh raised. Thanks to everyone's patience, it appears we have our
> consensus: this is a serious problem and we need a solution which
> satisfies these goals. So far there's one solution on the tabl
Kathey Marsden wrote:
Rick Hillegas and Kathey Marsden wrote:
[lots of stuff about implementation details that probably should wait
a bit]
I think Dan's summary and focus on goals was good:
Dan said ...
I think the goal should be to support auto-loading and to ensure
applications that perf
Rick Hillegas and Kathey Marsden wrote:
[lots of stuff about implementation details that probably should wait a bit]
I think Dan's summary and focus on goals was good:
Dan said ...
I think the goal should be to support auto-loading and to ensure
applications that perform some setup and then ex
Kathey Marsden <[EMAIL PROTECTED]> writes:
> Olav Sandstaa wrote:
>
>> Kathey Marsden wrote:
>>
>>> 3) If derby booted at the first connection or the first
>>> instantiation of the driver (whichever came first) , would that
>>> solve the derby.drda.startNetworkServer problem.
>>
>>
>> This depend
Kathey Marsden wrote:
Olav Sandstaa wrote:
Kathey Marsden wrote:
3) If derby booted at the first connection or the first
instantiation of the driver (whichever came first) , would that
solve the derby.drda.startNetworkServer problem.
This depends on what you mean by "the first instanti
Rick Hillegas wrote:
>
> 1) Remove the JDBC4-driver-autoloading. This removes a useful
> ease-of-development feature and makes us fail to be JDBC4-compliant.
>
> 2) Don't boot the engine when registering the embedded driver. Instead,
> boot the engine the first time that someone requests an embe
Olav Sandstaa wrote:
Kathey Marsden wrote:
3) If derby booted at the first connection or the first instantiation
of the driver (whichever came first) , would that solve the
derby.drda.startNetworkServer problem.
This depends on what you mean by "the first instantiation of the
driver". Wi
On 6/17/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:
It is probably worthwhile documenting this Heisenbug somewhere in our
user guides and release notes. In addition, two solutions have been
proposed for eliminating the extra exposure introduced by JDBC4. Neither
of these approaches addresses the
Kathey Marsden wrote:
I'll analyze some usage scenarios that I am aware of and see what the
impact might be. The most important thing is that this be a
deliberate choice and that we not rush new functionality and
introduce a regression where there is a reasonable technical
alternative, whe
Rick Hillegas wrote:
This topic was raised in an earlier email thread
(http://comments.gmane.org/gmane.comp.apache.db.derby.devel/20899) but
it does not appear that we agreed on a solution. I would like to re-open
this topic and hopefully we can converge on how we want to handle this
issue.
Jean T. Anderson wrote:
> Rick Hillegas wrote:
>>Jean T. Anderson wrote:
>>>Rick Hillegas wrote:
> ...
>>>Does the "precedence for properties" documentation need to be updated to
>>>mention jdbc 4/jdk 1.6 behavior?
>>>
>>>http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html
>
>>I don't
Rick Hillegas wrote:
> Jean T. Anderson wrote:
>> Rick Hillegas wrote:
...
>>
>> Does the "precedence for properties" documentation need to be updated to
>> mention jdbc 4/jdk 1.6 behavior?
>>
>> http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html
> I don't see that the precedence of
Kathey Marsden wrote:
Rick Hillegas wrote:
I'm afraid I don't understand why we would want to revert our tests
to the old behavior. It seems to me that our tests are practicing
stunts which we strongly discourage: changing Derby properties on the
fly. In general, there will always be Heise
Jean T. Anderson wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
David Van Couvering wrote:
- Log a bug
- Work on fixing it by booting on first connection rather than when
the driver is loaded.
It would be good to get input from the user community as well. One
Rick Hillegas wrote:
I'm afraid I don't understand why we would want to revert our tests to
the old behavior. It seems to me that our tests are practicing stunts
which we strongly discourage: changing Derby properties on the fly. In
general, there will always be Heisenbugs for applications w
Rick Hillegas wrote:
> Kathey Marsden wrote:
>
>> David Van Couvering wrote:
>>
>>>
>>> - Log a bug
>>>
>>> - Work on fixing it by booting on first connection rather than when
>>> the driver is loaded.
>>>
>> It would be good to get input from the user community as well. One
>> possible approach
Kathey Marsden wrote:
David Van Couvering wrote:
- Log a bug
- Work on fixing it by booting on first connection rather than when
the driver is loaded.
It would be good to get input from the user community as well. One
possible approach would be to log the bug, mark it as a regression,
David Van Couvering wrote:
- Log a bug
- Work on fixing it by booting on first connection rather than when
the driver is loaded.
It would be good to get input from the user community as well. One
possible approach would be to log the bug, mark it as a regression,
existing application im
My vote:
- Document it for 10.2
- Log a bug
- Work on fixing it by booting on first connection rather than when the
driver is loaded.
-1 on removing the autoloading feature, unless people have evidence that
this is going to cause real problems for our users.
David
Rick Hillegas wrote:
Th
This topic was raised in an earlier email thread
(http://comments.gmane.org/gmane.comp.apache.db.derby.devel/20899) but
it does not appear that we agreed on a solution. I would like to re-open
this topic and hopefully we can converge on how we want to handle this
issue.
Olav has analyzed a pr
20 matches
Mail list logo
