db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Wed, 14 Sep 2005 19:14:19 GMT
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...



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?

View raw message