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

David

> -- 
> Jeremy

Mime
View raw message