JDBC/Engine separation, was: Size of common jar file

[Jeremy Boynes <jb...@apache.org>]

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

Re: JDBC/Engine separation, was: Size of common jar file

[David Van Couvering <Da...@Sun.COM>]

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