db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject JDBC/Engine separation, was: Size of common jar file
Date Wed, 20 Jul 2005 19:46:17 GMT
David Van Couvering wrote:
> Hi, Jeremy, I like your idea of a "revolutionary" branch but (a) have no 
> idea how to set one up and (b) I don't think I have the "karma" yet to 
> do it.
> 

a) is easy, just svn copy what you need to a suitable location under 
'branches' and merge in your local changes. When the revolution is over 
the branch either gets merged to trunk or deleted

To do that you need b) which is blocked waiting for root to create your 
account.

> I also was planning to do what you call "small but crucial refactoring." 
>  First glance was not that promising though.  I have been able to keep 
> out all the storage-related services, for the most part.
> 
> This really isn't about the embedded JDBC driver being tied to the 
> engine.  It's more that the services themselves have lived a long life 
> under the assumption that they're running within the engine.
> 

Which services are involved and can we isolate them? I would have 
thought that the JDBC code could use a form of "in-VM" transport to 
separate itself from the engine at a much higher level than the storage 
level.

I would also wonder if there is a need for an "in-VM, cross-classloader" 
configuration that would allow multiple applications to use different 
JDBC versions but a common engine. I can see use for that when Derby is 
embedded in an IDE like Eclipse or in an appserver where the engine is 
running separate from the applications (e.g. different protection domain).

--
Jeremy

Mime
View raw message