I think Dan has really hit the nail on the head. All debate will
quickly stop if we reach consensus that it's not acceptable to break
compatibility (it's not really a regression, we never had this
constraint on ordering before) in this way as part of a minor release
(e.g. 10.1 to 10.2).
I don't know the environment that the customers who depend this on work
in. I don't know how flexible they can be to ordering how jars are
loaded. It's really hard for us to answer this without their input.
Could those of us who have these customers possibly talk to them and
discuss this and understand what their constraints are? I think it's
reasonable to document this for future customers; I don't personally
think it's a major usability issue, the vast majority of users will work
with a single version of Derby in a given VM.
Note that the main reason these customers want to run with different
versions, as I understand it, is so that they can run with a version of
the client that matches the server version. If we can guarantee
compatibility between client and server versions (so, for instance, you
can upgrade the server without having to upgrade the clients, or vise
versa), does this requirement goes away? I know at Sybase we never had
this issue because the TDS protocol allowed you to negotiate the version
of the protocol you were going to run at -- the server knew how to
"downgrade" its protocol support if it needed to. This type of
negotiation and compatibility guarantee is something Rick Hillegas is
already working on...
Thanks,
David
Daniel John Debrunner wrote:
Kathy Saunders wrote:
Thank you very much for the clear explanation. From a usability
perspective, I would vote for approach 2. Requiring a classpath to be
in a particular order is always an issue. However, the saving grace is
that it sounds like the ordering issue only comes up if you mix versions
of the derby.jar and the derbyclient.jar in the same classpath. I don't
believe most users put the client and engine in the same classpath
(unless there's a new requirement I don't know about), so that
definitely helps. Requiring classpath in a specific order can easily
lead to complications though, so I'm not in favor of it in general.
Derby's client and engine may be in the same classpath and at different
versions if the JVM is hosting more than one application, or the
application installers have modified the system/user's classpath to add
their required jars.
The issue is that today this is fully supported because the client and
engine do not share code.
Some of the code sharing approaches regress Derby in this area by not
supporting this, or require class path ordering for it to be supported.
While it is true that multiple class loaders solve the issue, this
approach is not always possible, I believe, for example, some of the
major application servers do not support different class loaders for
different JDBC providers (eg. the Derby client at 10.3 and engine and 10.2).
Thus the argument really is, are we willing to accept regression in this
area to gain code sharing, or should the code sharing solution not
regress Derby?
Dan.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
