db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: JDBC/Engine separation, was: Size of common jar file
Date Wed, 20 Jul 2005 20:01:08 GMT

Jeremy Boynes wrote:

> 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.
OK, thanks

>> 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'll try to summarize all this once I have worked through things a 
little more myself.

> 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).

An interesting idea, kind of like local EJBs.  My understanding is right 
now each application has its own database environment, and you can't 
share data across applications in an app server -- going across 
classloaders is pretty much identical to trying to go across VMs -- not 
allowed if you're running embedded mode.

I may be mistaken, but I don't think you can solve this through futzing 
with Java VM semantics.  I think you need an "in-memory" version of DRDA 
-- perhaps using a memory-mapped NIO buffer as a DRDA message queue... 
Way beyond the scope of what I'm working on :)


> -- 
> Jeremy

View raw message