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: VOTE: Principles of sharing code
Date Fri, 28 Oct 2005 22:27:57 GMT


Kathey Marsden wrote:
> David W. Van Couvering wrote:
> 
> 
>>You also avoid strange behavior such as slightly different SQL States
>>between client and server,
> 
> 
> There is absolutely nothing stopping you from using the same source
> property files that we have for server for client messages.  They aren't
> java files so don't have the same problems of cloning and can  let you
> get the  messages localized without all this controversy  I think.

That's actually not true.  The server-side messages are *huge* and are 
currently not available in derbyclient.jar.  Adding them would cause 
major client bloat (on disk if not at runtime), and only a small 
percentage of them are shareable.  This problem isn't solvable by 
cutting/pasting code.  If I don't want client bloat, I'd have cut/paste 
all shared messages *and* their translations.

It makes much more sense to migrate shared messages to a common 
location.  This requires a shared code infrastructure.

> 
> <snip a whole bunch of stuff about future needs>
> 
>>In terms of your particular issue, I'd like to challenge that it is as
>>bad as you say it is.
>>
>>Why would someone want to run at different patch versions of the same
>>minor version in the same VM
> 
> 
> See my response to Rick.  Nobody wants it they just get it.  It is one
> totally unrelated appllication affecting another.

I want to make sure I understand.  I think you're saying that there can 
be situations where there is a VM which gets its classes in some 
untransparent way.  For example, Application A puts its classes in one 
directory and Application B puts its jars in another directory, and then 
the VM is configured (somehow) to load classes from the union of these 
directories.  I'm sure there are other examples, but this is the one 
that comes to mind.

The common thread here is there is an application hosting environment 
where multiple applications are deployed into the same VM, and if the 
same jar files are deployed into both applications, then you can not 
guarantee that a particular instance of a class within these duplicated 
jars will actually be loaded at runtime, unless you carefully manage 
your classloading order or using separate classloaders.

It seems to me that in such an environment Derby already has this 
problem.  If Application A is running an embedded database and 
Application B is running an embedded database, and the Derby jar files 
for A precede B in the classloading order, then a bug fix in the engine 
code for B will be shadowed by the code in A.  The same is true if two 
applications are running with the network client and have a separate set 
of Derby jar files.

So what shared code is introducing is an incremental increase in the 
environments where such problems already exist, where one application is 
running with the network client driver and another is running the 
embedded driver.

It would seem to me the situation where there are two applications both 
running embedded would be more likely than the network/embedded case. 
Yet none of us seem to have ever heard anyone complaining that they have 
encountered this shadowing problem (or I'm sure it would have come up in 
the context of this discussion).  My suspicion is that this is because 
such an environment is extremely rare, if it exists at all.  All 
application hosting environments I know of use classloaders, and this 
type of shadowing issue is one of the primary reasons for this.

At any rate, my main point is I don't think that shared code is 
introducing a major regression to the product.

> 
> We need, I think, to discourage jar mixing  by changing the
> documentation to encourage application developers to use classloaders to
> insulate their application and protect others from it, printing warnings
> to the log file when jars are mixed or there is more than one copy or
> version of derby in the classpath,  providing a way to print sysinfo to
> the log when  classes have been loaded with classloaders and possibly
> even deprecating the ability to mix jars if the community wills it
> because of the impact on development, but it can't happen overnight like
> this.  It is an application developer  education issue and even those
> that understand the need for classloaders now  need some notice.
> 

I would be happy to write some information to the log so people know 
they have mixed versions.  This would help with the problem that already 
exists, and will continue to help when we have shared code.

To your point about "not doing this overnight," I suspect what you're 
saying is "warn people about it in 10.2 and then do it in 10.3". You 
also seem to indicate that you feel all the needs for shared code are 
"future needs."

I'm not convinced of that.  I think that, particularly as the community 
continues to grow, there is a timely need for this that really can't 
wait another year (assuming six month cycles for minor releases) before 
it sees the light of day.  I am sure I am not the only one who is 
working on a feature where shared code would help or is needed.  I know 
Rick wants to do this, and I suspect there are others.

I'd like to poll other folks on this list for their own views on this 
(I'll send it on a separate email to make sure it's called out).

Thanks,

David


Mime
View raw message